
Calhoun 

Iniiiiuiiortfl Arthivcof (he Navjl Pwigndualt School 


Calhoun: The NPS Institutional Archive 
DSpace Repository 



Theses and Dissertations 


1. Thesis and Dissertation Collection, all items 


2011-09 

Design requirements for weaponizing 
man-portable UAS in support of 
counter-sniper operations 

Graves, Gwendolyn M. 

Monterey, California. Naval Postgraduate School 


http://hdl.handle.net/10945/5543 


This publication is a work of the U.S. Government as defined in Title 17, United 
States Code, Section 101. Copyright protection is not available for this work in the 
United States. 


Downloaded from NPS Archive: Calhoun 



DUDLEY 

KNOX 

LIBRARY 


Calhoun is the Naval Postgraduate School's public access digitaI repository for 
research materials and institutional publications created by the NPS community. 
Calhoun is named for Professor of Mathematics Guy K. Calhoun, NPS's first 
appointed —and published —scholarly author. 

Dudley Knox Library / Naval Postgraduate School 
411 Dyer Road / 1 University Circle 
Monterey, California USA 93943 


htt p ://w w w. n ps.edu/l ib ra ry 







NAVAL 

POSTGRADUATE 

SCHOOL 

THESIS 


THE UNITED STATES NAVY RESERVE COMPONENT’S 

ACCOUNT MANAGEMENT CHALLENGE IN A NAVY 

MARINE CORPS INTRANET ENVIRONMENT 


by 


Gwendolyn M. Graves 


September 2005 

Thesis Advisor: 

Glenn Cook 

Second Reader: 

Mark Krause 


Approved for public release; distribution is unlimited 




THIS PAGE INTENTIONALLY LEFT BLANK 



REPORT DOCUMENTATION PAGE 


FormApprovedOMBN(h 0704-018i 5 

Public reporting burden for this collection of information is estimated to average 1 hour per response, including 
the time for reviewing instruction, searching existing data sources, gathering and maintaining the data needed, and 
completing and reviewing the collection of information. Send comments regarding this burden estimate or any 
other aspect of this collection of information, including suggestions for reducing this burden, to Washington 
headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 
1204, Arlington, VA 22202-4302, and to the Office of Management and Budget, Paperwork Reduction Project 

(0704-0188) Washington DC 20503, _ 

2. REPORT DATE 
September 2005 


6. AUTHOR(S) Gwendolyn M. Graves 


11. SUPPLEMENTARY NOTES The views expressed in this thesis are those of the author and do not reflect the official 
policy or position of the Department of Defense or the U.S. Government._ 


13. ABSTRACT (maximum 200 words) 

Declining budgets and the reduction of workforce has caused many organizations to perform additional 
job assignments with fewer personnel. These organizations realized that in order to survive in a competitive 
market, scarce resources would provide the most value if used to work on mission-essential tasks, while allowing 
the performance of support functions by an outside source (called outsourcing). The Department of the Navy 
(DoN) is one organization that has chosen to outsource many business areas, but none bigger than the outsourcing 
of information technology (IT) to form the Navy Marine Corps Intranet (NMCI)—the largest IT outsourcing 
contract to date. 

While the DoN has faced many challenges since the onset of the NMCI contracting agreement, this thesis 
focuses on the challenges faced by the Navy Reserve with managing the Intranet’s user accounts. The research 
uses the principles of Business Process Redesign (BPR) and Knowledge Management (KM) to determine the 
current state (As-Is) and to recommend changes in the account management process. Specifically, the 
Knowledge-Value Added (KVA) methodology was used to determine the amount of knowledge quantitatively 
embedded in each sub-process for a relative comparison of the value that the sub-processes provide to the overall 
process._ 


16. PRICE CODE 


NSN 7540-01 -280-5500 Standard Form 298 (Rev. 2-89) 

Prescribed by ANSI Std. 239-18 


20. LIMITATION 
OF ABSTRACT 

UL 


15. NUMBER OF 
PAGES 

219 


14. SUBJECT TERMS 

Navy Marine Corps Intranet, NMCI, Seat Management, Outsourcing, U.S Navy Reserve Component, 
Navy Reserve, Account Management, Knowledge Value Added, KVA, Return On Knowledge, ROK, 
Business Process Redesign, BPR, Knowledge Management, Measuring Knowledge 

18. SECURITY 
CLASSIFICATION OF THIS 
PAGE 

Unclassified 


19. SECURITY 
CLASSIFICATION OF 
ABSTRACT 

Unclassified 


17. SECURITY 
CLASSIFICATION OF 
REPORT 

Unclassified 


12b. DISTRIBUTION CODE 


12a. DISTRIBUTION / AVAILABILITY STATEMENT 

Approved for public release; distribution is unlimited 


7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) 

Naval Postgraduate School 
Monterey, CA 93943-5000 

9. SPONSORING /MONITORING AGENCY NAME(S) AND ADDRESS(ES) 

Commander, Navy Reserve Force, Chief Information Officer 
4400 Dauphine Street, New Orleans, LA 70146-5000 


5. FUNDING NUMBERS 


8. PERFORMING 
ORGANIZATION REPORT 

NUMBER _ 

10. SPONSORING/MONITORING 
AGENCY REPORT NUMBER 


4. TITLE AND SUBTITLE: The United States Navy Reserve Component’s 
Account Management Challenge in a Navy Marine Corps Intranet Environment 


3. REPORT TYPE AND DATES COVERED 

Master’s Thesis 


1. AGENCY USE ONLY (Leave blank) 


1 




























THIS PAGE INTENTIONALLY LEFT BLANK 


11 



Approved for public release; distribution is unlimited 


THE UNITED STATES NAVY RESERVE COMPONENT’S ACCOUNT 
MANAGEMENT CHALLENGE IN A NAVY AND MARINE CORPS INTRANET 

ENVIRONMENT 

Gwendolyn M. Graves 
Lieutenant Commander, United States Navy 
B.S., Dillard University, 1993 


Submitted in partial fulfillment of the 
requirements for the degree of 


MASTER OF SCIENCE IN INFORMATION TECHNOLOGY MANAGEMENT 


from the 


NAVAL POSTGRADUATE SCHOOL 
September 2005 


Author: Gwendolyn M. Graves 


Approved by: Glenn Cook 

Thesis Advisor 


Mark Krause 
Second Reader 


Dan C. Boger 

Chairman, Department of Information Sciences 



THIS PAGE INTENTIONALLY LEFT BLANK 


IV 



ABSTRACT 


Declining budgets and the reduction of workforce has caused many organizations 
to perform additional job assignments with fewer personnel. These organizations 
realized that in order to survive in a competitive market, scarce resources would provide 
the most value if used to work on mission-essential tasks, while allowing the perfonnance 
of support functions by an outside source (called outsourcing). The Department of the 
Navy (DoN) is one organization that has chosen to outsource many business areas, but 
none bigger than the outsourcing of information technology (IT) to form the Navy 
Marine Corps Intranet (NMCI)—the largest IT outsourcing contract to date. 

While the DoN has faced many challenges since the onset of the NMCI 
contracting agreement, this thesis focuses on the challenges faced by the Navy Reserve 
with managing the Intranet’s user accounts. The research uses the principles of Business 
Process Redesign (BPR) and Knowledge Management (KM) to detennine the current 
state (As-Is) and to recommend changes in the account management process. 
Specifically, the Knowledge-Value Added (KVA) methodology was used to determine 
the amount of knowledge quantitatively embedded in each sub-process for a relative 
comparison of the value that the sub-processes provide to the overall process. 
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GLOSSARY OF TERMS AND DEFINITIONS 


Account - Capability to provide a person or function access to the NMCI Network and 
services and is chargeable against the ledger. 

Account ledger - Accounting system that provides the capability to track every individual 
account status and corresponding digital identity. 

Active Account - an account that has registered signs of activity and is also chargeable. 

Active Directory 1 - A central component of the Windows platfonn, Active Directory 
directory service provides the means to manage the identities and relationships that make 
up network environments. It is a centralized and standardized system that automates 
network management of user data, security, and distributed resources, and enables 
interoperation with other directories. 

Chargeable Account - NMCI account that is actively used by individual or in a functional 
role including e-mail and access to NMCI resources. 

Claimant - a claimant denotes the next level of management below the Chief of Naval 
Operations headquarters staff within the budget arena. In the Navy’s tradition of 
relatively decentralized management, the major claimants are the focal point for 
executing the Strategic Sourcing Program. 

Contract Line Item 0024 (CLIN 0024) - an additional non-classified account that 
provides a user account in addition to those provided with ordered data seat(s). 

Contract Line Item 0026AL (CLIN 0026AL) 2 - an NMCI contract item referred to as a 
Move Add Change (MAC). A MAC is an administrative logical change to a user account 
not associated with provisioning of an ordered Contract Line Item (CLIN). They are 
separated into three categories with some chargeable and some non-chargeable. 

Deactivated - An account where access to NMCI is no longer permitted but the digital 
identity and flat name space is retained for future use on NMCI. 

Deleted - Account completely deleted from NMCI. 

Disabled - An account that is not accessible and all e-mail is rejected. 


1 Information obtained from the following websites (Accessed April 2005): 
http://www.google.com/search?hl=en&lr=&oi=defmore&q=defme:Active+Directorv ; 
http://www.microsoft.com/windowsserver2003/technologies/directorv/activedirectory/default.mspx 

2 Information from the NMCI website (Accessed April 2005): 
http://www.nmci.navv.mil/Primary Areas/Contract/Content/Files/Contract Artifacts/Conformed Contract/ 

N00024-00-D-6000 Attachl-P00129.pdf 
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Echelon - An Echelon is a Civil War term used to describe the arrangement of military 
troops during battle. In this document, it is defined as the hierarchy or separation of 
military command or of a headquarters. The lower the echelon number, the higher the 
command in the reporting chain. For instance, an Echelon II command is one level above 
an Echelon III in the reporting chain of command 

Identity - Identities are pieces of information that identify a users association of 
existence. 

Identity and Access Management - a set of processes and technologies to more 
effectively and consistently manage user objects over relatively large numbers of systems 
and directories. 

Locked - Account not able to be accessed by individual but e-mail will continue to be 
routed to the mailbox. 

New Account - Account that has never been established on the NMCI Network. Usually 
the result of: Accession or New Employee (Civilian). 

Non-Chargeable Account - NMCI Account that has been deactivated and the member 
does not have access to NMCI. 

Pending - Account Established but has not been accessed by user. 

Provisioning - The automation of business-oriented work flow of systems, resources, 
services and devices to employees, partners, contractors, suppliers and temporary 
workers. 

Reactivated Accounts - A Deactivated Account that has been reestablished with stored 
digital identity. 

Seat Identification - a unique eight (8) digit number assigned to each seat entered into the 
NMCI Enterprise Tool (NET) database. Every asset that is considered a seat in NET is 
assigned a SeatID. Any peripherals that are attached to a seat do not have its own 
SeatID. If a peripheral is ordered as a seat (stand alone) then it would have its own 
SeatID. 

Stale - System indicates a locked account that has remained inactive for over 30 days 
with no attempts to utilize the account. 
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I. 


INTRODUCTION 


A. PURPOSE 

This thesis analyzes how the U.S. Navy Reserve is currently managing Navy 
Marine Corps Intranet (NMCI) accounts. The research defines seat management, 
provides a brief history of NMCI, identifies the As-Is process for account management 
and the associated significant challenges, provides an analysis of “best-of-breed” 
commercial-off-the-shelf (COTS) products used by industry for account management, 
and outlines best practices of commercial companies that have adopted the seat 
management concept. It also explores and proposes a non-technical enterprise solution 
that could feasibly be implemented by Commander, Navy Reserve Force (CNRF) to 
minimize the current account management challenges. 

B. BACKGROUND 

Government agencies have been implementing seat management concepts with 
information technology (IT) contracting since 1997. Also known as desktop outsourcing, 
seat management is the process where organizations outsource the maintenance and 
ownership of their desktop personal computers (PCs), including all required hardware, 
software, network support, and help desk services to commercial companies that 
specialize in those services. Simply stated, seat management involves buying desktop 
computing power as a unified service with pricing computed on a “per user” or a “per 
seat” basis, hence, the term seat management. One method of a seat management 
environment allows the contractor to maintain ownership of all the resources such as 
network and desktop hardware and software, and delivers the resultant computing 
capability as a service, often compared to a utility. 

The NMCI contract, arguably the largest and most complex seat management 
effort attempted to date, was awarded in October 2000 as a multi-year performance-based 
contract. Awarded as an indefinite deliver/indefinite quantity (IDIQ) contract with 
Electronic Data Systems (EDS) Corporation as the prime contractor, NMCI is expected 
eventually to provide service for roughly 400,000 Navy and Marine Corps personnel. 
The contract is valued between $9-$ 13 billion and was awarded as a five-year base 
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contract covering fiscal years 2001 through 2005, with a three-year option period 
continuing into fiscal years 2006-2008. 

There can be many benefits derived from seat management contracting and the 
development of the NMCI naturally inherited many of these benefits. With proper 
structuring of the requirements and the contract, commercial expertise and best practices 
can be leveraged to result in improvements such as quality improvement, better response 
time, higher reliability and availability, and/or reduced system downtime. While 
organizations that embark on a seat management approach hope to save money, most 
realize benefits are in the area of quality improvement. 

Management of these benefits present many challenges for the organizations that 
have chosen to embrace seat management. The structure of the Department of the Navy 
(DoN) and the diversity in its business processes caused the management of NMCI to be 
unique and more complex than the management of such contracts in the commercial 
sector. The large number of transient military personnel that relocate every two to three 
years for new military assignments and the numerous geographically dispersed shore- 
based commands that reside on the Intranet adds to the complexity of information 
technology (IT) management in the NMCI environment. One of the many challenges 
involves the management of all associated accounts that reside on NMCI in addition to 
the unused accounts affiliated with each seat. This challenge continues to haunt the U.S. 
Navy Active Component (USN AC) and the U.S. Navy Reserve Component (USN RC) 
resulting in an estimated additional cost of $35 million per year. 

The objective of this thesis is to analyze the current processes associated with 
account management. Recommendations are provided on improvements to simplify the 
management of accounts and decrease the $35 million additional annual cost. 

C. RESEARCH QUESTIONS 

1. Primary Research Question 

How might the U.S. Navy Reserve Component (USN RC) effectively manage 
accounts in the NMCI environment? 
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2. Secondary Research Questions 

• How were the accounts allocated during NMCI deployment? 

• How are the USN RC Customer Technical Representatives (CTRs) 
currently tracking NMCI accounts per region? 

• How is the Navy Reserve Forces Command currently managing NMCI 
accounts for the USN RC? 

• How is the U.S. Navy Active Component (USN AC) currently managing 
NMCI accounts? 

• How are some of the large commercial companies, which have adopted 
the seat management concept, successfully managing accounts across an 
enterprise solution? 

• What are the ‘best-of-breed’ COTS products used by industry for account 
management? 

• What would be a feasible non-technical solution that the USN RC, and 
perhaps the USN AC, could implement? 

D. SCOPE AND LIMITATIONS 

The scope of this thesis includes an in-depth analysis of the USN RC’s current 
process and the sub-processes involved in managing NMCI accounts. This analysis 
defines and outlines the As-Is process for account management. The scope analyzes how 
commercial companies that have implemented the seat management concept are 
managing their remote locations and the feasibility of the USN RC implementing a 
similar solution. “Best-of-breed” COTS tools used by industry for account management 
were reviewed for feasibility of use as a management tool by the USN RC. The 
recommendations include a non-technical solution for minimizing the current challenges 
affiliated with account management. The analysis is from a business process perspective. 
Therefore, a software solution is not provided as a deliverable and is beyond the scope of 
this thesis. 

E. METHODOLOGY 

The methodology used to fulfill the requirements for this thesis consisted of the 
following steps. First, a comprehensive literature review of journal articles, General 
Accounting Office (GAO) reports, and other library information resources was conducted 
to understand the history of NMCI and its progression. Second, an in-depth content 
analysis was conducted of official websites, presentations, and journals to understand the 
pertinent NMCI contract tenns and current business process. Third, phone interviews, a 
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review of presentation material, and a review of official documents were utilized to grasp 
the USN RC implementation, cutover plan, and key challenges with NMCI. Fourth, a 
web-based survey, followed by phone interviews, was primarily used to gather data on 
the manner in which accounts are currently managed within various commands across a 
myriad of echelons. 3 The results of the survey were used to determine the relationship 
between each of the sub-processes and their correlation. Fifth, web research and phone 
interviews were conducted to gather data from commercial companies that have 
implemented the seat management concept successfully. Sixth, coordination with 
vendors and web research was the method used to analyze “best-of-breed” COTS 
packages used in industry for account management. As a result of these steps, the 
researcher was able to evaluate the effectiveness of the current account management 
process, perform a feasibility analysis, and make recommendations for an enterprise 
solution to account management. 

F. BENEFITS OF THE RESEARCH 

This thesis analyzes how the USN RC is coping with the current account 
management challenges and defines the current state (i.e., As-Is model) of managing 
accounts. Additionally, it provides an analysis of COTS packages that could consolidate 
several applications that are currently used for account management, analyzes 
commercial companies that have implemented the seat management concept and 
identifies best practices used to make seat management successful in their environment. 
Recommendations are provided on how the USN RC can better manage accounts by 
making modifications to the current information technology systems, establishing an 
enterprise solution, and by making changes in the business processes. Implementation of 
these recommendations is expected to yield a cost savings of approximately $35 million 
and to create an efficient and standardize management process. This study could not only 
benefit the USN RC, but also the USN AC as they are also faced with similar NMCI 
challenges. 


3 An Echelon is a Civil War term used to describe the arrangement of military troops during battle. In 
this document, it is defined as the hierarchy or separation of military commands or of a headquarters. The 
lower the echelon number, the higher the command in the reporting chain. For instance, an Echelon II 
command is one level above an Echelon III in the reporting chain of command 
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G. ORGANIZATION OF THE THESIS 

Chapter II provides a comprehensive history of NMCI and the road to transition 
completion for the USN RC. Chapter III gives a detailed analysis of the challenges 
associated with managing accounts. Chapter IV defines the methods used to determine 
the current state, identifies how the data was obtained to determine the current state, and 
provides a detailed outline of the current sub-processes associated with account 
management. Chapter V provides an in-depth analysis of “best-of-breed” COTS products 
as well as an analysis of industry best practices for outsourced seat management 
contracts. Chapter VI provides recommendations for an enterprise solution for managing 
accounts. It also contains research conclusions and answers to the research questions. 
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II. NMCI HISTORY AND THE ASSOCIATED BENEFITS 


A. INTRODUCTION 

This chapter discusses the history of the NMCI program to establish the 
background and reference point for the analysis of the associated account management 
challenges presented later in the thesis. It also provides a description of the NMCI 
program and the inherent benefits of seat management contracting. 

B. DRIVING FACTORS FOR THE NEED TO CHANGE 

Prior to the inception of NMCI, Department of the Navy (DoN) was faced with 
many challenges and shortfalls in IT management, acquisition, and operations. The 
declining manning levels and budget led to reductions in military and civilian personnel. 
The competition created by industry made it increasingly difficult to retain a highly- 
skilled IT workforce. The rapid growth and evolution of technology outpaced DoN’s 
ability to remain current, and thus resulting in obsolete business processes, antiquated 
infrastructure, and legacy computers riding on low speed network circuits. Declining 
budgets did not match IT requirements for hardware and software refreshment, which led 
to IT assets being retained longer than recommended by industry standards without 
maintenance contracts to support them. Funding was given to the larger System 
Commands (SYSCOMs) and the Research and Development (R&D) labs to build and 
design technologically advanced networks to support their mission. These commands are 
called the “haves” while the smaller commands were given minimal IT funding and yet 
were required to work with antiquated systems that caused them to expend a good portion 
of their resources to managing and maintaining the systems. These commands are 
frequently considered the “have-nots”. [Ref. 7] 

Joint Vision 2010 mandated that future operating environments strongly 
emphasize the decisive advantage conferred by superior information management and 
knowledge dominance in order to achieve operational success and information 
superiority. Knowledge dominance is defined as the ability to establish a force that can 
leverage technology to access knowledge and quickly share information in the form of 
education, learning, training, and human expertise using a networked joint architecture. 
Infonnation superiority can be defined as providing military forces with the capability to 
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collect, process, and disseminate an uninterrupted flow of infonnation while exploiting or 
denying an adversary’s ability to do the same. In a non-combat situation this means that 
U.S. forces would have the necessary information to achieve their operational objectives. 
In order to provide the operational environment necessary to promote infonnation 
superiority, connectivity is necessary between all parts of shore establishments, and with 
all deployed forces at sea and ashore. This connectivity would enable an environment in 
which all members can collaborate freely, share information, and organizational learning 
can be fostered. [Ref. 6], 

The DoN reshaped its vision to support the speed, volume, and diversity of 
knowledge required to operate effectively within the framework of joint military forces. 
DoN is building the infrastructure necessary to achieve information superiority and 
support knowledge dominance. Ashore, the infrastructure takes the form of the Navy 
Marine Corps Intranet (NMCI) that will ultimately connect all DoN ashore facilities and 
pennit rapid, secure, infonnation transfer, and universal Internet access. 

C. NAVY MARINE CORPS INTRANET (NMCI) 

NMCI is a corporate-style Intranet that links Navy and Marine Corps shore-based 
installations. The NMCI contract was awarded in October 2000 as one of the DoN’s 
responses to the requirement of Joint Vision 2010 to obtain information superiority [Ref. 
1]. The contract was designed using the principles of seat management in order to reap 
the benefits inherent in seat management concepts. It is a multi-year performance-based, 
indefinite deliver/indefinite quantity (IDIQ) contract with a dollar value ranging $9-$ 13 
billion with Electronic Data Systems (EDS) Corporation as the prime contractor and 
includes a five-year base period covering fiscal years 2001 through 2005 with a three- 
year option period. Once Full Operational Capability (FOC) is reached, the Intranet is 
expected to provide network services for roughly 400,000 U.S. Navy and Marine Corps 
shore-based computer workstations, also called “seats.” 

The concept behind the NMCI transformation effort is to apply the speed and 

opportunities of Internet technology not only to warfighting tasks, but also to the daily 

activities of personnel, and especially those dealing with administrative and support 

tasks. The purpose of NMCI is to provide the Navy and Marine Corps with secure 

universal access to integrated voice, video and data communications (ViViD) as well as 
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to eliminate interoperability problems across stove-piped networks and to remove 
anomalies in the network thereby improving productivity and speed of command. It also 
includes classified and unclassified connectivity in its architecture to make it arguably 
one of the most robust, comprehensive, enterprise-wide outsourced seat management 
contracts to date. One of the primary goals identified in the NMCI contract is to bring the 
Navy and Marine Corps’ disparate information technology ashore systems together under 
a single vendor to increase security and interoperability. The ultimate goal is to allow 
DoN operators to focus on their mission rather than be concerned with IT services and all 
the technical problems related with infrastructures and administration activities. 

D. EXPECTED BENEFITS OF NMCI 

With the implementation of NMCI, DoN was able to take advantage quickly of 
the several benefits that are potentially inherent in a seat management contract. Once 
fully implemented, the NMCI contract will consolidate Navy and Marine Corps networks 
that are scattered over 300 military bases into a single enterprise-wide managed service. 
The benefits received from this enterprise approach include improved interoperability and 
access as the consolidation of networks and locations will eliminate locally built stove- 
piped systems. Consolidating the IT budget at the U.S. Navy Active Component (USN 
AC) and the U.S. Navy Reserve Component (USN RC) Echelon II levels enabled 
increased visibility of IT costs. Enterprise-wide quality improvements have also been 
realized in the form of better response time, more reliable system availability, and 
reduced downtime. 

Another benefit of NMCI is improved security. Consolidating the stove-piped 
networks to form an enterprise-wide solution has exponentially increased security 
throughout DoN. When consolidating networks, multiple access points are eliminated 
reducing points of vulnerability in the system. [Ref. 5]. NMCI provides stringent 
information assurance support and increases the level of security management to 
unprecedented heights across DoN. 

“Technology refreshment” is another advantage of seat management contracting. 
Technology refreshment has been defined as the periodic replacement of commercial-off- 
the-shelf (COTS) components such as processors, displays, operating systems, and 

software, to support the continued operation of the system through an indefinite service 
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life. Technology refreshment is a way to extend the useful life of IT resources while 
keeping abreast of technological advances. Such planned upgrades not only ensure that 
systems stay current with the latest commercial technology, they also allow the 
organization to stay ahead of the “obsolescence curve.” [Ref. 8] 

Information technological advances have been coming so quickly and thus 
resulting in a huge burden for an organization to plan and budget for upgrades in the 
traditional fashion. By incorporating a technology refreshment requirement into the 
NMCI seat management contract, EDS becomes responsible for planning and 
implementing the upgrades at no additional costs beyond the already kn own seat pricing. 
The NMCI contract, for example, contains technology refreshment requirements that 
software be updated annually or to maintain one revision from the current state, while 
hardware is updated every three years. [Ref. 9]. Military organizations like the Navy 
Reserve would have not been able to maintain such technology refreshment requirements 
without the implementation of NMCI. 

Another benefit of NMCI is that it allows DoN to divert personnel resources 
previously performing routine tasks associated with desktop IT resources (e.g., helpdesk 
personnel). By transferring the ownership and responsibility for the resources to 
commercial vendors who specialize in IT support, DoN personnel can focus on the 
command’s core mission rather than running desktop systems. This benefit of NMCI is 
even more important today since the Government is finding it more difficult to compete 
with the private sector for IT personnel. By freeing agency personnel from the day-to-day 
routine support tasks, they can perform other, potentially more interesting work and more 
business sensitive tasks. Meaningful work may help to retain critical IT professionals. 

With NMCI, DoN obtains secure seamless end-to-end, integrated service delivery 
of desktop systems, including hardware and software upgrades, technical support and 
training. They will simply pay a fixed monthly fee for those services based on a per-seat 
calculation. Outsourcing seat management effectively shifts responsibility for keeping 
pace with technological changes to the contractor, “who must be knowledgeable, 
adaptable and capable of constantly assessing how to deliver better, more cost-effective 
desktop services to the end user.” [Ref. 4] 
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E. CHAPTER SUMMARY 

This chapter provided an overview of the inception of NMCI and its connection to 
Joint Vision 2010. In addition, the chapter also provided a historical view of the 
multitude of services provided by NMCI. Many are inherent in seat management 
contracting and some are unique to the NMCI contract. The chapter concluded with an 
examination of the benefits of NMCI and the harvesting opportunities realized by DoN. 
The next chapter provides a detailed examination of the account management challenges 
and concerns of the USN RC. 
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III. THE ACCOUNT MANAGEMENT CHALLENGE 


A. INTRODUCTION 

The development of the Navy Marine Corps Intranet (NMCI) provides an 
enterprise-wide solution to seat management that connects all Navy and Marine Corps 
commands on one network platform. The Navy Reserve senior leadership realized the 
benefits of such a network and fully embraced the concept as they encouraged a rapid 
implementation of NMCI by their subordinate commands. 

The U.S. Navy Reserve Component (USN RC) was considered to be one of the 
“have-nots” as they were operating old hardware (in some cases with Pentium II and 
Pentium III computers), outdated software applications (some were running Microsoft 
Windows 98 operating system), and antiquated peripherals to support the Full Time 
Support (FTS) and the Drilling Reservists (DRILLRES) personnel assigned to their Navy 
Reserve Activity (NRA). They were required to operate with a reduced IT budget and 
were not able to keep abreast of the pace of technology. The USN RC leadership realized 
that the establishment of the NMCI would provide them with modern technology across 
all NRAs and would standardize equipment and services across DoN. 

While learning from some of the early lessons of their U.S. Navy Active 
Component (USN AC) counterparts during their NMCI cutover and planning, the 
information technology leadership of the USN RC began to develop plans, common 
profiles, and demand models that would assist in their NMCI transition. Reserve 
commands were cutting over to NMCI and ordering accounts at a rapid pace. They soon 
realized that account management would become a problem as DRILLRES and FTS 
began to transfer to other NRAs, be recalled to active duty, and retire or resign while their 
accounts remained active at the losing command. The transient personnel began to 
relocate faster than the Navy Reserve senior leadership could detennine the process and 
set policy for handling the accounts. As the race to the NMCI cutover began, so did the 
challenge of account management. The Navy Reserve senior leadership realized that 
they were in need of an enterprise solution to account management as an estimated cost 
savings of approximately $35 million could be achieved. 
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Although NMCI is very beneficial, many challenges remain in managing such a 
large-scale contract. The focus of this chapter addresses the problems incurred by the 
USN RC with managing over 80,000 accounts for DRILLRES, Reserve FTS, and civilian 
personnel in the NMCI environment. Although the focus is on the USN RC, this problem 
is not unique to them but is also experienced by the USN AC as well. 

B. THE CHALLENGE IN ORGANIZATIONAL STRUCTURE 

When the NMCI contract was awarded, DoN still had many areas that required 
clearly defined processes and management standards. Account Management is one of the 
areas that lacked a standard enterprise-level process, which led to the problems that are 
experienced today. The initial intent was to manage the accounts at the Echelon II level 
and it was at this level that “the enterprise” would be defined. Management, to include 
acquisition and budget, at the Echelon II level meant that DoN would be responsible for 
the overall management of accounts and would have access to the NMCI operating and 
funding requirements of both the USN AC and the USN RC. All accounts were to be 
aggregated and distributed at the enterprise level. [Ref. 10] 

The definition of “the enterprise” did not evolve as initially intended with the 
final award of the contract. The decision was that overall management would occur at 
the Echelon II claimant 4 levels of the USN AC and the USN RC instead of combining 
them under the USN AC as an effort to simplify the management. These Echelon II 
commands would then be responsible for all NMCI management under their claimancy, 
which further required that all budgeting and fiscal responsibility for NMCI also be given 
to each based on their individual requirements. Thus began the account management 
challenges of today. 

When the NMCI contract was awarded, the DoN and the contractor agreed to 
couple the “seats” with user accounts. The anticipated seat purchase was expected to be 
roughly 400,000 and it was believed that adding user accounts to the seat for one cost 
would not only provide the computers, also called the “seat”, but would also allow 
additional user accounts to be assigned to the hardware at no additional charge. It was 

4 A claimant denotes the next level of management below the Chief of Naval Operations headquarters 
staff within the budget arena. In the Navy’s tradition of relatively decentralized management, the major 
claimants are the focal point for executing the Strategic Sourcing Program. 
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decided to arrange the contract so that each unclassified “seat” would be accompanied 
with two “free user accounts” and that each classified “seat” would lend five accounts 
“per seat”. This approach was to eliminate the need for DoN to purchase a large quantity 
of additional user account services from the contract as the two “free user accounts” that 
would accompany the 400,000 unclassified seats would be sufficient to cover the DoN 
for a total of 800,000 accessible accounts. 

The initial goal was to have an aggregated “pool” of all the unused user accounts 
remaining from the 800,000 that would be accessible by all of DoN. When needed, 
accounts would be allocated from the pool and deposited back to the pool when an 
account is no longer in use. The 800,000 free user accounts were expected to cover the 
majority of the users requiring access to NMCI and DoN would pay a minimal service 
cost for any additional accounts that exceeded this amount. 

Separating the two Echelon II claimants when defining “the enterprise” (USN and 
USN RC) dampened this plan as each of the claimants could now only have access to the 
seats that were included in their NMCI service order, and subsequently, the accounts that 
accompanied each of those seats. No business rules were developed to allow accounts to 
be shared between the claimants to achieve the intended costs savings for DoN. This 
structure created problems for the Navy Reserve because they would require a plethora of 
additional user accounts above the total derived from their seats. 

The USN RC structure and requirements are unique when compared to its USN 
counterpart. With most of its 80,000 plus force in DRILLRES status, there was not a 
requirement to have a large number of seats but a need existed to have a large number of 
accounts. The aforementioned definition of the enterprise caused them to order a large 
number of additional user accounts from the NMCI service contract as the total free 
accounts that were derived from the seat order were not sufficient. In fiscal year 2004, it 
was estimated that USN had approximately a surplus of 70,000 unused accounts while 
the USN RC was required to purchase support services for approximately 30,000 
accounts at a cost of approximately $700 for each account per annum. The lack of 
visibility and accessibility across claimants led the USN RC to spend approximately $30 
million dollars for additional user accounts. 


15 



C. COMMAND MANAGEMENT 

The NMCI contract is a service contract that allows its customers to decide what 
services they want and order those services from the contractor. The services are 
identified as Contract Line Items (CLINs) and are ordered by the government’s 
representative called a Customer Technical Representative (CTR). Appendix A includes 
a list of the CLINs. The CTRs are located at the Echelon II level and possess overall 
contract management responsibility on behalf of the government. The CTR also has 
lower level representatives, called the Deputy Customer Technical Representative 
(DCTR) and Assistance Customer Technical Representative (ACTR), who are 
responsible for daily NMCI management at their local NRA. The business rules have 
established a distinct difference in responsibility between them as the ACTR (also called 
an authorized initiator), who is responsible for sending any request that requires 
contractor action and funding approval to the DCTR (also called an authorized 
submitter). In addition to managing the local accounts, the DCTR is responsible for 
reviewing and submitting any requests generated by the ACTR and has been granted 
authority by the CTR to authorize any funding requirement to support submitted requests. 
For the purpose of this thesis, the tenns technical representative and account manager is 
used synonymously. 

Although the CLINs and their description appear in Appendix A, one of the 
problems with account management involves the management of CLIN 0024 (Additional 
Non-Classified Account) and CLIN 0026AL (Administrative Move Add Change). Per 
the contract, CLIN 0024 is defined as “an additional Non-Classified Account that 
provides a user account in addition to those provided with ordered data seat(s).” The 
price for a CLIN 0024 is $58.26 per month or approximately $700 per annum [Ref. 11]. 
It is important to note that the problems identified in the previous section of a high 
account-to-seat ratio have resulted in the USN RC paying for over 30,000 CLIN 0024’s. 
A CLIN 0026AL is defined as an administrative Move, Add, Change (called a MAC). 
Most CLIN 0026AL’s are a one-time chargeable transaction for a service provided by the 
contractor for modifications to current hardware/software configurations and accounts. 
The area of concern for this thesis is charges accrued because of account-generated 
MAC’S. The price for each CLIN 0026AL request is $36.60. 
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Management of accounts by the technical representatives has also been a 
challenge. The lack of policy and standards and a single integrated IT solution has 
caused the technical representatives to spend an enormous amount of time reconciling 
what seats and user accounts the IT management systems say they have and what is 
actually on-site. 

Business processes are not in place to direct the proper management of a user 
account from its inception to the termination of service (cradle to grave). The following 
sections provide more detail on the types of issues that the USN RC is currently 
experiencing with account management. 

1. Duplicate Accounts 

Problems exist with technical representatives establishing new accounts for users 
that already have an NMCI account in Active Directory whereby creating what is called a 
duplicate (or excess) account, which increases the user account total and the requirement 
for CLIN 0024’s. For those managers that are investigating whether an account already 
exists before submitting a request for a new account, they are not properly trained on 
which databases or systems should be used to verify a user’s status. Many check the 
Global Address Lists (GAL) for verification, but should also verily account status in the 
Active Directory. The GAL and Active Directory differ in that the GAL provides a list 
of email addresses while the user account is actually generated in Active Directory. A 
user may not necessarily have an email address listed in the GAL, but may have a 
chargeable account listed in Active Directory. Conversely, the GAL may contain 
multiple email accounts for users that are not listed in Active Directory. In order for a 
manager to accurately detennine all the duplicate accounts, communication would be 
required with an NMCI system administrator to gain access to both the hidden and visible 
accounts in Active Directory. Many scenarios exist in which a duplicate account can be 
created. In order for the reader to understand the challenge, the next two paragraphs 
provide two examples of the types of scenarios that could result in the creation of a 
duplicate account. 

A duplicate account can be difficult to determine when a user has a common 

name (i.e., John Smith). An example is a current NMCI user with a common name who 

reports to a gaining command. The technical representative asks if a NMCI user account 
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already exists and John Smith, having never used his NMCI account before, says that one 
does not exist. The technical representative checks the GAL or Active Directory, notices 
a large number of John Smith’s in the system, and therefore, elects to create a new 
account for the user. The user now has an account created from a previous command and 
a newly-created user account from his new command. For the Navy Reserve, this would 
equate to payment of two CLIN 0024s if the two “free” accounts that accompanied the 
seats are completely occupied. 


Example 1: Creation of Duplicate account 




Figure 1. Duplicate Account Creation Example 1. 


Duplicate accounts are also difficult to detennine when an inadvertent creation is 
made when a user is transferring to a new location while his losing command is preparing 
for NMCI transition. For example, a user (i.e., John Doe) was previously located at a 
command (for instance, San Diego) that was in the beginning phases of transition (called 
cutover) to NMCI. The local ACTR submitted an account creation request for John Doe 
when the command’s initial NMCI order was submitted. In the middle of the San Diego 


18 




































transition, John Doe relocates to another command (for instance, Washington D.C.) and 
he was unaware that the San Diego NRA initiated a pending service request to create a 
new account. The Washington D.C. command, having already cutover to NMCI, submits 
a request to have a new account created for John Doe and the newly created account 
name is John Doe 2. The submission of the request for a new service results in the 
claimant paying for a duplicate account for John Doe. 


Example 2: Creation of Duplicate account 


Transferring Command 
(San Diego) 




ACTREchV 



Usef 


Figure 2. Duplicate Account Creation Example 2. 


Possibly the worse case scenario for creating a duplicate account is when a local 
account manager intentionally does not verify if an account exists in any of the available 
database resources when a user reports to the command. In some cases, negligent 
management oversight has been the cause of duplicate account creation. 
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Although not all-inclusive, the aforementioned examples provide insight into the 
possibility of an account manager creating duplicate accounts in a highly complex 
management process. 

2. Multiple Accounts 

The unique nature of the Navy Reserve requires some personnel maintain a 
duplicate account with valid reason. A duplicate account that has been justified by the 
claimant is called a multiple account. Multiple accounts are valid accounts that are given 
based on a job or “role” that the account holder may perfonn in an organization. A 
DRILLRES may have a Reserve account funded by the USN RC claimant, and another 
separate NMCI account for a civilian occupation funded by the claimant over that 
organization. The “role”, or job function, of an NMCI user detennines the need for 
multiple accounts. 

For example, a DRILLRES will have a Reserve account. Depending on the job 
functions and the level of access required, it is possible that a civilian occupation requires 
NMCI access, and thus, a separate unclassified account may be required. As a 
DRILLRES, special access might be required to a classified network, which will require 
a third NMCI account. The separate account would be required for the classified network 
because the unclassified and classified NMCI networks are physically separated for 
security reasons. Since they are physically separated, there is a different Active 
Directory and different servers that support the network, and therefore, require a different 
account. An NMCI user could have many accounts depending on the “roles” that must 
be performed. The “role” is what drives the account creation, and thus, increases the cost 
for managing each of those additional accounts when purchasing a CLIN 0024. 

3. Inactive or Unused Accounts 

Currently, the USN RC is paying for personnel accounts that have transferred to 
active duty, separated or retired from the Navy Reserve, transferred to a non-NMCI 
command, and even deceased personnel. Accounts for users that fall in one of these 
categories have shown no activity and are categorized as an inactive or an unused 
account. However, funding is still allocated to cover the cost of these accounts. 
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Figure 3 outlines the six categories of accounts. [Ref. 12] Of these categories, 
chargeable unused accounts are categorized as active, locked, stale, or disabled. An 
“active” account is a chargeable account actively used by an NMCI account holder. An 
account that is “locked” is a chargeable account that is not accessible by a NMCI account 
holder. A “stale” account is a NMCI system term used to identify an account that has 
remained inactive for over 30 days with no attempts to utilize the account. A “disabled” 
account is a chargeable account status not accessible and all email is rejected. An account 
is placed in this status when a user has not attempted to access NMCI. All of these cases 
produce unnecessary additional costs for the USN RC and the DoN. 
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Figure 3. Draft NMCI Instruction. 


A report produced by EDS in December 2004 revealed that there were 
approximately 18,600 accounts that fell into one of these categories. [Ref. 10] Action 
should be taken to move these accounts to one of the non-chargeable categories of 
deactivation or deletion, but there is resistance in arbitrarily doing so without approval 
from the Echelon II claimant. The Navy Reserve continues to pay for these accounts 
even with substantial evidence of no activity. 

4. Excessive Move, Add, Change Request 

Transferring user accounts to other NMCI commands requires the technical 
representative to submit a chargeable MAC request, or CLIN 0026, to the DCTR. Close 
coordination is required by both the transferring command and the gaining command to 
alleviate multiple MAC submissions for the same account. For example, the technical 
representative is notified that an NMCI user will be transferring from the local command. 
The transferring technical representative submits a MAC to have an account deactivated 
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while a member is in travel status. This is one chargeable transaction. When the member 
reports, the gaining command submits a MAC to have the member’s account transferred 
to their activity and could possibly generate a third MAC to have the account reactivated. 
This creates another chargeable transaction. Proper coordination between the losing and 
gaining command could have eliminated the need for multiple MACs and required the 
payment for one CLIN 0026. 

5. Multiple Stove-Piped IT Systems 

Since a single-integrated NMCI IT management tool does not exist, technical 
representatives are required to use multiple IT systems to perfonn overall account and 
seat management. Data residing in a myriad of systems generates problems with data 
synchronization and accuracy. The NMCI Enterprise Tool (called NET) is a web-based 
portal used as a data repository for recording information about all seats and peripherals 
at each site. Simply stated, it is DoN’s inventory management system and also is the 
gateway used to order services to be delivered on NMCI. Initially, it was built to 
maintain a record of hardware and software. A later version enabled some account 
information, in the form of profiles, to be added by the users, but the database is not an 
accurate reflection of the accounts existing in each command and is not robust enough to 
include all the information required to manage accounts properly. In its current 
configuration, NET does not effectively perfonn the account management function. 
Additionally, technical representatives must use the Global Address List (GAL) or Active 
Directory to verify the status of a new or existing account of gaining or transferring 
personnel since the account data is currently inaccurate in NET. 
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NET.HelpDesk@lmco.com 



Figure 4. NMCI Enterprise Took Web Portal. 


Technical representatives are required to use a separate tool to validate NMCI seat 
and account orders. Electronic Marketplace (called eMarketplace) is the web-based tool 
used to perform monthly validations on billing invoices. The validation is a method of 
verifying that the contractor is billing for existent services at their location. Some 
interface between NET and eMarketplace exists but the two systems are not properly 
synchronized, and therefore, the data does not match. 
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Figure 5. eMarketplace Website. 


MACs are submitted and managed using a separate web-portal called the Service 
Request Electronic Form (SR eForm). The SR eForm is the contactor’s tool for 
managing MAC requests. The technical representative must enter any request for a MAC 
into the SR eForm and the request is eventually routed to the contractor electronically. 
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Figure 6. Service Request Electronic Form Web Portal. 
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Since most of these management systems do not interface with each other and are 
not fully integrated, the data contained in them are not synchronized across the enterprise 
and a true corporate data repository does not exist. The lack of a fully integrated system 
requires the technical representatives to pull data, in some cases redundant data, from 
each to perform daily routine tasks. Currently, the array of systems has created an 
intense manual process, and in their current configuration, these systems do not 
effectively support account management. The various IT stove-piped systems have 
caused inefficiencies in the overall account management process for the contractor and 
the Navy Reserve. 

D. CHAPTER SUMMARY 

This chapter provided a detailed examination of the significant challenges and 
concerns associated with account management. These challenges involve the current 
organizational structure which disallows account aggregation or sharing between the 
claimants; the lack of policy and procedural guidance for account managers causing them 
to create local procedures that may not include all areas of account management; the 
different types of account creation (i.e., duplicate, multiple, and Inactive accounts) that 
causes excess chargeable account to the USN RC, and the multitude of stove-piped IT 
account management systems. They have hindered the current account management 
process and have made it ineffective. Addressing these challenges and integrating the 
systems would achieve an increase in the benefits of the NMCI contract while creating a 
more effective and efficient account management process. 

The next chapter provides a detailed analysis of the current state, called the As-Is, 
of the NMCI account management process across the Navy Reserve. User surveys and a 
process to measure the knowledge in each task were used to determine the current state 
and the amount of value each task provides to the overall organization. 
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IV. 


THE CURRENT PROCESS OF ACCOUNT MANAGEMENT 


A. INTRODUCTION 

This chapter describes and analyzes the U.S. Navy Reserve Component’s (USN 
RC) current approach to managing accounts. The necessity of capturing the current 
process was crucial before making recommendations on modifications to the process. 
While several methods were used to identify the current process, the theory of 
determining the amount of knowledge required to generate the outputs of the overall 
process, and each of the sub-processes, proved beneficial in detennining the value that 
each sub-process provides to account management. This methodology, called 
Knowledge Valuation Analysis or Knowledge Value Added (KVA), measures the 
amount of knowledge required to generate the outputs of a process or sub-process in 
common units of measurement. 

This chapter provides a general overview to Knowledge Management (KM), the 
principles of KVA, the use of KVA to perform Business Process Redesign, and how each 
was used to complete the research in this thesis. Additionally, the chapter describes the 
methodology used to capture the detailed analysis of each sub-process currently involved 
in managing accounts. Lastly, the chapter identifies the knowledge levels currently 
embedded in each sub-process and their relative comparison in the overall account 
management process. 

B. KNOWLEDGE MANAGEMENT 

The fundamental building material and engine of wealth of the modern 
corporation is the creation and utilization of knowledge. The real challenge in the 
Information Age is to understand how to accelerate the conversion of knowledge into 
money through understanding how to measure knowledge assets. [Ref. 13] Knowledge 
has value that must be managed and invested just as organizations manage their human 
resources, equipment, and financial resources. In many ways, it is considered the most 
valuable asset within an organization because the knowledge increases the more it is used 
within a process. Oftentimes, organizations refer to their organizational knowledge as 
“Intellectual Capital.” This term is appropriate because although it may be difficult to 
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assign organizational knowledge a monetary value, it is still an important commodity 
nonetheless. 

Many knowledge enthusiasts profess that the idea of managing the knowledge in 
an organization has begun to surpass common business strategies of managing 
investment capital. The onset of the knowledge era and the evolution from the Industrial 
Age to the Information Age has caused a progression in management that shifts the focus 
from managing people to managing intellectual capital. This transfonnation has caused 
many companies to realize that their success is contingent upon how successful they are 
at managing the knowledge within their organization. Organizations are constantly 
finding ways to capture and share knowledge effectively and efficiently as a means of 
creating value and reducing costs within the business processes. 

The field of Knowledge Management has sparked interest in many organizations 
worldwide. In simplest terms, knowledge management can be defined as the practice of 
promoting the generation of new knowledge, the codification of knowledge, and 
providing availability or transfer of that knowledge all to reap the greatest benefit (profit) 
from the asset. Knowledge management also entails the measurement of knowledge. 
Skandia Corporation, an international insurance company, has begun to publish an 
Annual Report supplement to its financial statement that outlines their Intellectual 
Capital. In their book Measuring and Managing Knowledge, Housel and Bell describe 
knowledge management as a “way to detennine what knowledge should be privately held 
and how it can be protected from competitors and clients.” [Ref. 14:p. 8] This is 
important as a company’s competitive advantage, in fact, often lies in its privately held 
knowledge. 

With a company’s success dependent upon its ability to manage and leverage 
knowledge assets effectively, competitive focus has shifted from trying to “out-do” one 
another to trying to “out-know” one another [Ref. 14]. Enterprises are realizing how 
important it is to “know what they know” and to be able to make maximum use of the 
knowledge. This knowledge resides in many different places such as databases, 
knowledge bases, filing cabinets, and in the heads of employees and are distributed 
across the enterprise. All too often one part of an enterprise repeats work already done by 
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another part simply because there has not been careful tracking of organizational 
expertise or experiences. Most traditional company policies and controls focus on the 
tangible assets of the company and leave unmanaged their important intangible 
knowledge assets. Knowledge management is forcing enterprises to determine what their 
knowledge assets and core competencies are and how to manage and make use of these 
assets to obtain maximum return. 

Success in an increasingly competitive marketplace depends critically on the 
quality of knowledge organizations apply to their key business processes. For example, 
the supply chain depends on knowledge of diverse areas including planning, raw 
materials, manufacturing, and distribution. Likewise, product development requires 
knowledge of consumer requirements, new science, new technology, marketing etc. 
[Ref. 15] Achieving success is accompanied by many challenges that can dictate whether 
an organization maintains or gains the competitive advantage. 

The challenge of deploying the knowledge assets of an organization to create a 
competitive advantage becomes more crucial as [Ref. 15]: 

• The marketplace, at the local and global levels, is increasingly competitive 
and the rate of innovation is rising, so that knowledge must evolve and be 
assimilated at an ever-increasing rate. 

• Corporations are organizing their businesses to be focused on creating 
customer value. Staff functions and management structures are being 
reduced. There is a need to replace the informal knowledge management 
of the staff function with formal methods in customer aligned business 
processes. 

• Competitive pressures are reducing the size of the workforce which holds 
this knowledge. 

• Knowledge takes time to experience and acquire while employees have 
less time to gain the experience and acquire the knowledge. 

• There is a need to manage increasing complexity as changes in strategic 
direction may result in the loss of knowledge in a specific area. 
Subsequent reversal in policy may then lead to renewed requirements for 
this knowledge but the employees possessing that knowledge may no 
longer exist within the organization. 

1. Knowledge in the Context of Knowledge Management 

While many definitions exist for knowledge, there is still a level of complexity in 

understanding the manner in which it can be employed in the various fields of study. To 
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implement knowledge management successfully within an organization, the managers 
must be able to define knowledge before they can begin to manage it. 

At issue is the definition of knowledge management and the component concepts. 
Thomas Davenport, in discussing knowledge management and related concepts, has 
presented the following ideas [Ref. 16]. 

Data are a set of objective facts about events or structured records of transactions. 
These records may give quantity, cost, color, size, but usually fail to record why the 
purchase was made, how likely it is a repeat purchase, request for a service, or the 
occurrence of an event. 

Information on the other hand is “usually in the form of a document or an 
audible or visible communication. Information has a sender and receiver and is intended 
to change the way the receiver perceives something. “It's data that makes a difference 
Information moves around organizations through hard networks with visible and definite 
infrastructure, wires, delivery vans, satellite dishes, post offices, addresses, electronic 
mailboxes and soft networks or informal networks often invisible and less formal. 

Knowledge is usually recognized as broader, deeper and richer than data or 
information. Davenport and Prusak define knowledge as: 

a fluid mix of framed experience, values contextual information, and 

expert insight that provides a framework for evaluating and incorporating 

new experiences and infonnation. It originates and is applied in the minds 

of knowers. 

In organizations, knowledge often becomes embedded not only in documents or 
repositories but also in organizational routines, processes, practices, and norms. 

Knowledge assets are the tacit and explicit knowledge-creating objects such as 
markets, products, technologies, and organizations that a business owns or needs to own 
and which enable its business processes to generate profits, add value, etc. Explicit 
knowledge is that which has been easily articulated and is simple to transfer from one 
person to another. Nonaka and Takeuchi state that it can be expressed in words and 
numbers, and easily communicated and shared in the form of hard data, scientific 
formulae, or codified procedures [Ref. 18]. It is easy to codify and can normally be found 
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shared in documents, databases, and other tangible media. Examples of explicit 
knowledge include chemical formula, market forecasts, software code, and technical 
standards. Conversely, tacit knowledge has an increased level of difficulty when trying 
to capture and share it because it is subconsciously understood and developed from direct 
experience and action [Ref. 19]. Tacit knowledge is “deeply rooted in an individual’s 
action and experience, as well as in ideals, values or emotions: that have developed 
within an individual.” [Ref. 18] Knowledge management is not only about managing 
these knowledge assets but also about managing the processes that act upon the assets. 
These processes include developing knowledge; preserving knowledge; using knowledge, 
and sharing knowledge. 

Therefore, Knowledge Management involves the identification and analysis of 
available and required knowledge assets, knowledge asset-related processes, and the 
subsequent planning and control of actions to develop both the assets and the processes 
so as to fulfill organizational objectives. Knowledge management is not only about 
managing these knowledge assets but managing the processes that act upon the assets. 
These processes include developing knowledge; preserving knowledge; using, and 
sharing knowledge. 

Although some writers like Karl-Erik Sveiby define knowledge management as 
“the art of creating value from intangible assets” [Ref. 20], implementation of knowledge 
management in fact involves activities in information management, information 
technology, and human resources development. Component activities of knowledge 
management have been undertaken by librarians and other information professionals, 
educators, database administrators and other information technology personnel. 

What then makes the difference between the normal activities of these 
professionals and ventures into knowledge management? An important factor is the 
emphasis on achieving organizational strategies, and the consequent need for cultural 
change, increased teamwork, integration of content and information technologies and 
continuing development of related organizational policies. 
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2. The Role of Information Technology in Knowledge Management 

The concept of treating organizational knowledge as a valuable strategic asset has 
been popularized by leading management and organization theorists. Organizations are 
being advised that to remain competitive, they must efficiently and effectively create, 
locate, capture, and share their organization’s knowledge and expertise. They must also 
demonstrate the ability to bring that knowledge to bear on problems and opportunities. 

Although knowledge management is becoming widely accepted, few 
organizations are fully capable of developing and leveraging critical organizational 
knowledge to improve their performance [Ref. 19]. Many organizations have become so 
complex that their knowledge is fragmented, difficult to locate and share, and therefore, 
redundant, inconsistent or not used at all. In today’s environment of rapid change and 
technological discontinuity, even knowledge and expertise that can be shared is often 
quickly made obsolete. The reach of know-how and experience possessed by individuals 
can be greatly extended once it is captured and explicated so that others can easily find, 
understand and use it. 

The information technology infrastructure should provide a seamless “pipeline” 
for the flow of explicit knowledge to enable [Ref. 19]: 

• Capturing knowledge 

• Defining, storing, categorizing, indexing and linking digital objects 
corresponding to knowledge units; 

• Searching for (“pulling”) and subscribing to (“pushing”) relevant content, 

• Presenting content with sufficient flexibility to render it meaningful and 
applicable across multiple contexts of use. 

The focus is on the technologies that capture, store, and distribute structured 
knowledge for use by people. The goal of these technologies is to take knowledge that 
exists in human heads and paper documents, and various disparate systems and media, 
and make it widely available throughout an organization [Ref. 17]. Information 
technologies such as the World Wide Web offer a potentially useful environment within 
which to build a multimedia repository for rich, explicit knowledge. Input is captured by 
forms for assigning various labels, categories, and indices to each unit of knowledge. The 
structure is flexible enough to create knowledge units, indexed and linked using 
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categories that reflect the structure of the contextual knowledge and the content of factual 
knowledge of the organization, displayed as flexible subsets via dynamically 
customizable views. 

Effective use of information technology to communicate knowledge requires an 
organization to share an interpretive context. The more that communicators share similar 
knowledge, background and experience, the more effectively knowledge can be 
communicated via electronically mediated channels [Ref. 23]. Michael Zack stated in his 
research in Managing Codified Knowledge that at one extreme, the dissemination of 
explicit, factual knowledge within a stable community having a high degree of shared 
contextual knowledge can be accomplished through access to a central electronic 
repository [Ref. 19]. However, when interpretive context is moderately shared, or the 
knowledge exchanged is less explicit, or the community is loosely affiliated, then more 
interactive modes such as electronic mail or discussion databases are appropriate. When 
context is not well shared and knowledge is primarily tacit, communication and narrated 
experience is best supported with the richest and most interactive modes such as video 
conferencing or face-to-face conversation [Ref. 19]. 

In understanding the role of IT in knowledge management, it is important to 
emphasize that IT is an enabler of knowledge management rather than a driver. 
Subsequently, IT is only the pipeline and storage system for knowledge exchange. It 
does not create knowledge and cannot guarantee or even promote knowledge generation 
or knowledge sharing in an organizational culture that does not favor those activities 
[Ref. 17]. Technology alone will not force a person with expertise to share it with others. 
While technology is common in the domain of knowledge distribution, it rarely enhances 
the process of knowledge use. Extensive behavioral, cultural, and organizational change 
could cause a positive environment that would encourage knowledge use. 

IT is also relatively less helpful when it comes to knowledge creation, which 
remains largely an act of individuals or groups and their brains [Ref. 17]. Housel and 
Bell further highlight this by offering two principals that could make moving knowledge 
assets advantageous. First, simple and procedural knowledge that is employed frequently 
should be moved to IT. Relocating procedural knowledge like assembly line 
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manufacturing to IT drastically decreases the cost per usage of each unit of knowledge 
utilized. Second, organizations should seek to capture in IT the knowledge that typically 
dies when an employee leaves the company. The complex or tacit knowledge that an 
employee accumulates with years of experience is often indispensable and should be 
captured in IT to ensure continued operations. Capturing the knowledge in IT ensures the 
knowledge remains embedded throughout the processes and is accessible to any new 
process owners. While many organizations desire to capture this tacit knowledge 
embedded in the heads of its employees to gain or maintain the competitive advantage, 
providing such knowledge is left to the discretion of the employee and should be 
voluntarily provided without a violation of rights. 

C. KNOWLEDGE-VALUE ADDED 

The fundamental building material of a modern corporation is knowledge. Housel 
and Kanevsky [Ref. 13] state that the engine of wealth in today’s business economy is the 
creation and utilization of knowledge. Understanding how to accelerate the conversion 
of knowledge into money is one of the many challenges in the Information Age. This 
‘knowledge payoff occurs when an organization’s most valuable intangible asset - 
knowledge- is converted into bottom line value in the form of concrete, saleable products. 

The knowledge embedded in an organization’s structure (processes, technology, 
and people) is the genome that represents the code required for reproducing 
organizational products. This ‘code’ is virtually equivalent to the value added by the 
organization because it is what is necessary and sufficient to reproduce the organization’s 
products and services [Ref. 13]. 

It has been often stated that you cannot manage what you cannot measure. This 
notion has its roots in the understanding that a system requires feedback to keep it on 
track. What managers monitor and measure determines what feedback they obtain and 
how well their systems are geared to achieving their goals. The basic goal for monitoring 
and measuring knowledge is to detennine how well it is producing value in 
organizational processes. This requires following the use of knowledge throughout an 
organization’s core processes and its interactions with the marketplace. 
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Drs. Housel and Kanevsky recognized the need for an objective means for 
measuring organizational knowledge in common units and developed a methodology 
called knowledge-value added (KVA) to do this. KVA helps managers understand how 
to best leverage the knowledge resident in employees, infonnation technology, and core 
processes. The essence of KVA is that the knowledge utilized in core processes to 
generate organizational outputs can be translated into numerical form as a common unit 
of measure. This translation provides an indication of the value added by process 
knowledge and allows allocation of a benefit stream to that knowledge. Tracking the 
conversion of knowledge into value, while measuring its bottom-line impact, enables 
managers to increase the productivity of critical assets. 

Simply stated, KVA can be defined as a new method of gathering historical data 
about the outputs of an organization’s processes. These new data are described in a 
common unit of measure that reflects the amount of organizational knowledge required to 
produce the outputs. Once organizational knowledge has been quantified using KVA, it 
can be monetized and used in common performance ratios such as ROI and in new ratios 
such as knowledge in use compared to knowledge in inventory or knowledge in people 
compared to knowledge in IT. KVA can also be used to develop estimates of price per 
unit of knowledge as well as cost per unit of knowledge, using either monetized or non- 
monetized common units. 

1. KVA Theory 

In order to understand the concepts of KVA, it is important to understand the 
KVA value-adding cycle and the fundamental assumptions where it derives its validity as 
a knowledge measurement method. See Figure 7. 
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P(x)=y 

Process P is a business process. 

If input x is equal to output y, no value has been added by process P. 

If input x is changed by process P into output y, value has been added and is ~ change. 

Change can be measured by the amount of knowledge required to make the change. 

This knowledge « the amount of time it takes for an average learner to acquire the knowledge. 

So, value added by process ~ change ~ knowledge required to produce the outputs 

Housel, T. & Kanevsky, V. (1995) “Reengineering Business Processes: A Complexity Theory Approach to 

Value Added,” INFOR 33(4): 251. 

Figure 7. Fundamental Assumption of KVA (From: Ref. 13). 

Figure 7 illustrates these assumptions. 

• In any process, there is an input, a process that changes the input, and an 
output. 

• If the input is equal to the output, then the process adds no value. 

• If a process produces an output that is different from the input, then the 
amount of change is proportional to the amount of value added by the 
process. The “change” that takes place during the process is what creates 
value. 

• Change can be discussed in terms of the amount of knowledge that it takes 
to produce that change. 

• Therefore, there exists a proportional relation between value and the 
knowledge required to make change. 

By accepting the assumption that knowledge and change are proportional, it is 
then possible to use knowledge as a surrogate for value when assessing process units of 
outputs. Once the units of outputs are standardized into a common unit of measure, the 
knowledge, then is it feasible to make beneficial comparisons across multiple processes. 

2. How KVA Works 

What makes KVA a powerful tool is that it can be relatively simply defined in 

three different approaches, yet it is robust enough to produce a desired level of detail 

should managers desire a more comprehensive view of the organizational processes. 
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Housel and Bell have defined three different ways to establish the value of knowledge 
embedded in the IT systems and the people within an organization. See Figure 8. 


Steps 

Laarrxng time 

Process description 

Binary query method 

1 . 


identify core process and its suborocesses 

2. 

Establish common units to 
measure learning time 

Describe the products in terms 
of the instructions required to 
reproduce them and select unit 
ol process description. 

Create a set of binary yes,'no 
questions such that all possible 
outputs are represented as a 
sequence of yes/no answers. 

3. 

Calculate learning time to 
execute each subprocess. 

Calculate numbor of process 
instructions pertaining to 
each subprocess. 

Calculate length of sequence of 
yesi'no answers for each 
subprocess. 

4. 

Designate sampling time period long enough to capture a representative sample of the corn 
process s final productfcervice output 

5. 

Multiply the learning time lor 
each subprocess by the num¬ 
ber ol times the subprocess 
executes during sample period 

Multiply the number of process 
instructions used td describe 
each subprocess by the number 
of times the subprocess 
executes during sample period. 

Multiply the length ol the yes/no 
string for each subprocess by the 
number of times this subprocess 
executes during sample period. 

6 

Allocate revenue to subprocesses in proportion to the quantities generated by step 5 and calculate 
coats for each subprocess. 

7. 


Calculate ROK, and Interpret the results. 


Figure 8. Three Approaches to KVA (From: Ref. 14). 


Figure 8 summarizes each approach. 

• Learning Time: Learning time measures how long it takes an “average 
learner” to leam a function or process. Once the learning time has been 
determined, it is then multiplied by the number of times that function is 
performed over a predetermined period of time. 

• Process description: Describes products relative to the number of 
instructions required to reproduce them. Once the number of instructions 
has been detennined, it is then multiplied by the number of times the 
process executes. 

• Binary Query Method: Creates a set of binary yes/no questions such that 
all possible outputs are represented as a sequence of yes/no answers. 
Once the answers have been collected, multiply the length of the yes/no 
string for each of the sub-processes by the number of times the sub¬ 
process was executed. 

While Housel and Bell states that the Binary Query Method is the most accurate 
approach to doing KVA, it is also the most tedious and is most suitable for processes that 
require the highest degree of accuracy and granularity. This thesis utilizes the Learning 
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Time method to calculate the Return on Knowledge (ROK) for the Navy Reserve 
Account Management process. 

3. Return on Knowledge 

Industry has traditionally used ratio analysis to assist with detennining and 
measuring a company’s profitability and performance. One such ratio, commonly used 
by industry, is Return on Investment (ROI). ROI indicates how many dollars of profit are 
generated by each dollar of cost. It is used to help organizations make capital investment 
decisions, initiate future business solutions, and select the best course of action. While 
many benefits can be achieved by using ROI analysis, it falls short in the ability to reflect 
indirect costs and fluctuating returns accurately over time. The ROI is calculated by 
considering the annual benefit stream (or profit) divided by the cost associated with the 
benefit stream. The equation is simply: 

Revenue - Cost of Investment _ Net Benefit 
R OI =-. 

Cost of Investment Total Cost 

While commercial industry has reaped benefits in using ROI, such an analysis is 
difficult for not-for-profits such as the Department of Defense (DoD), in which a 
traditional “revenue stream” is not generated. Rather than using some extrapolation of 
cost in place of a revenue stream (for example, cost savings), KVA can assist DoD to 
measure and allocate a proxy for revenue that will enable it to determine the value of its 
knowledge-base assets (people, processes, and technology) that cannot be reflected in 
traditional ROI methodologies. KVA data populates a new ratio, Return on Knowledge 
(or ROK), which describes “returns” in terms of the number of units of knowledge that 
are generated by each unit of knowledge cost. Using Learning Time as a surrogate for 
the return in ROI, the ROK ratios can now be defined as: 

ROK = — 

c 


where: 

K = Knowledge generated by a single core process 

C = Cost assigned to Time to Complete a single core process, or surrogate for cost 
assigned 
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D. BUSINESS PROCESS REDESIGN 


Business Process Redesign (BPR) has had a major impact on organizations that 
have desired to make changes in their organizational processes to achieve higher levels of 
effectiveness and efficiency. The concept of BPR as a strategy to make modifications 
within organizational business processes began its history in the 1980’s. At that time, 
investments in IT did not result in corresponding improvements or increases in 
productivity and perfonnance. Many explanations were given as to why IT did not 
produce the results that were expected. Some blamed the IT and such things as the way it 
was being implemented, the user-unfriendly nature of software, the lack of managerial 
understanding of IT (called technophobic), the lack of information systems 
professionals understanding of business (called technocentric), and faulty implementation 
of IT [Ref. 22]. 

Years of continued failure of IT investments caused business to shift its focus. 
They began to realize that perhaps the IT systems were not to blame, but rather that 
organizational processes, structures and designs were not work-friendly. They realized 
that applying IT to traditional hierarchical structures, complex procedures, and antiquated 
organizational designs exacerbated the problems, and that automating them with IT 
cemented complex archaic structures through automation rather than improved them (El 
Sawy, 2001). This approach of applying IT to existing problems is simply an exercise in 
paving the cowpath 5 . 

As the competition begin to ramp up, many scholars began to research ways in 
which organizations could achieve faster cycle times, cost cutting, and improvements in 
customer responsiveness. The overwhelming desire was to find ways of performing 
business that would yield exponential increases in perfonnance. These scholars 
concluded that the demands could only be met by rethinking how business is performed 
and by taking advantage of the capabilities of IT. Hence, the BPR concept began to take 
industry by storm. 


5 Paving the cowpath refers back to the early part of this century, when people simply paved the 
traditional serpentine roads needed for animal-based transportation, rather than re-routing roads directly 
over the hill to take advantage of powerful automobile technology. In Information Technology, it refers to 
automating inefficient processes thus creating more inefficiency. 
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1. BPR Defined 

In order to understand BPR fully, first it is necessary to determine the definition 
of a business process. Davenport and Short (1990) define a business process as “a set of 
logically related tasks performed to achieve a defined business outcome.” It implies a 
strong emphasis on how work is performed within an organization. In their view, 
processes have two important characteristics: 1) They have customers (internal or 
external) and 2) They cross organizational boundaries (i.e., they occur across or between 
organizational subunits). Processes are generally identified in tenns of beginning and 
end point, interfaces, and organization units involved, particularly the customer unit. 
Conversely, El Sawy (2001) defines a business process by breaking down the letters in 
the BPR acronym. He states that the focus is on end-to-end business processes that 
extend to the customer the value of the process. He further indicates that the ‘B’ “defines 
the boundaries of a process in a way that makes sense in terms of business value: the 
coordination of ensembles of tasks perfonned by many people rather than narrow tasks 
performed by one person.” The ‘P’ in BPR has a “primary focus on essential processes 
that deliver outcomes is the signature of all variants of BPR rather than a focus on static 
organizational structures.” It looks primarily at dynamic process flows that move rather 
than static organizations structures. It is cross-functional in scope within an enterprise. 
He states that it is a coordinated and logically sequenced set of work activities and 
associated resources that produce something of value to a customer (El Sawy, 2001). 
While the definitions of a business process given by Davenport and El Sawy differ, both 
indicate that a process must have boundaries, relationships, and create an output. By 
examining the definition of a business process, a clearer understanding of BPR can now 
be gained. 

Much has been written about the concept in both the practitioner trade press and 
in academic research, yet finding a common definition of BPR has become an impossible 
task. Davenport and Short has defined BPR as “the analysis and design of workflows and 
processes within and between organizations” [Ref. 21]. El Sawy provides a more 
comprehensive definition as he states that BPR is a performance improvement 
philosophy that aims to achieve quantum improvements by primarily rethinking and 
redesigning the way business processes are executed [Ref. 22], 
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2. The Use of IT and BPR 

While both of these definitions slightly vary in meaning and in interpretation, 
both authors agree that the use of IT is the key enabler of BPR. Davenport and Short 
argued that BPR requires taking a broader view of both IT and business activity, and of 
the relationships between them. IT should be viewed as more than an automating or 
mechanizing force to fundamentally reshape the way business is done. They believe that 
business activities should be viewed as more than a collection of individual or even 
functional tasks in a process view for maximizing effectiveness. IT and BPR have a 
recursive relationship. IT capabilities should support business processes, and business 
processes should be in terms of the capabilities IT can provide. Davenport and Short 
(1990) refer to this broadened, recursive view of IT and BPR as the new industrial 
engineering. 

El Sawy indicates that the success of BPR is not solely reliant on the redesign of 
business processes. He states that the work environment around the business process 
may require some adjustments. He uses the Leavitt Diamond structure shown below to 
demonstrate this theory and to illustrate how BPR fits into an organization. Harold J. 
Leavitt developed the Leavitt Diamond (Figure 9) to demonstrate the relationships 
between four key functions of the BPR initiative. Managing the organizational variables 
of IT use, organizational fonn, requisite people skills, and business processes is 
imperative to ensure that the organization maintains the balance required for BPR 
success. For example, if a new IT is introduced into the organization, business processes 
may need to be changed to take advantage of the technology. The use of the new IT and 
the newly designed process may require new people skills to match, and perhaps a new 
organizational form (more centralized, or team-based, for example) [Ref. 22]. 
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Figure 9. The Leavitt Diamond. 

Understanding such a framework is critically important when redesigning 
processes that are knowledge intensive. As processes change and the remaining variables 
in the Leavitt Diamond are affected, changes in the knowledge that surrounds the process 
will likely change dynamically. It either departs with outgoing personnel or becomes 
useless because it resides in the heads of personnel who have been disassociated with the 
process. Thus, when redesigning processes, it is imperative to ensure that the knowledge 
about the process is considered and captured in the IT where feasible. 

3. Phases of BPR 

Table 1 and Figure 10 depict the phases of BPR, as defined by El Sawy, and what 
actions are completed in each phase. [Ref. 22] While this thesis focuses only on the first 
two phases, it is important to note that proper execution of Phase 3 is imperative in order 
to make the BPR IT solution successful. Figure 10 illustrates that the foundation for the 
success of the process redesign model is the requirement to share process knowledge. 
The sharing of this knowledge is required within each phase of the BPR cycle. Table 1 
provides each of the phases and the activities that accompany them. The information 
contained within the table provides enough high-level detail and little explanation of each 
is required. 
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Phase 1 

Scoping the process 

Phase 2 

Modeling, analysis, and 
redesign of process 

Phase 3 

Planning process 

Integration 

Activities 

• Operationalize process 
performance targets 

• Define process boundaries 

• Continue data collection 

• Model “As-Is" baseline 
process 

• Provide workflow model or 
requirements for IS design 

• Adjust process design 


Identify Key process issues 
Und?f?t9ncl prwtic^*? 
and define initial visions 
Outline data collection plan 
and collect baseline data 
Plan for modeling phase 


Analyze and diagnose *'As- 

ls*' process 

Design and model "To-Be” 
process alternatives 
Analyze “To-Bo” process 
alternatives and select best 
alternative 


Plan for process 
Implementation 


• Plan process integration 
phase 


Deliverables 


• Process Scoping Report 

• 

Software-Based Process 
Model 

• Process Integration Plan 


• 

Partner Impact Report 



• 

Process Reengineering 
Report 




Key Participants 


• Process Owners and 

• 

Process Participants 

• IS Design Team 

Partners 

• 

BPR Team 

• BPR Team 

• Customers of Process 

• BPR Team 





Table 1. Key Phases and Activities in BPR (From: Ref. 22). 


The phases are: 

• Phase 1: Scoping phase 

• This phase is used to define the inputs to the process undergoing 
change and the desired output to achieve. This phase keeps the 
BPR team focused and on course throughout the BPR process. 

• Phase 2: Modeling, Analysis, and Redesign phase 

• In this phase, a model of the current or “As-Is” process is drafted, 
analysis of the As-Is is conducted and then future process 
alternatives or “To-Be” processes can be modeled, analyzed for 
best performer and then the plan for phase 3. This phase is the 
focus of research performed in this thesis. 

• Phase 3: Planning Process Integration phase 

• This phase is designated for drafting a plan for integrating the new 
process alternative for smooth, seamless integration of the new 
process into the current organization. 
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Figure 10. Phases of Business Process Redesign (From: Ref. 22). 

A large portion of the information in this chapter was derived by utilizing the 
processes included in Phase 2. While the KVA methodology of Housel and Bell was 
used to capture the knowledge in each sub-process, El Sawy’s BPR phase approach 
assisted with determining when the knowledge should be captured. The methodology 
and theories of both Housel and Kavesky for KVA and El Sawy for BPR were used in 
defining the As-Is and the To-Be for NMCI account management. 

E. DEFINING THE CURRENT PROCESS FOR ACCOUNT MANAGEMENT 

This section provides the supporting research data and shows how the KVA 
methodology and BPR principles were used to perform data collection, model the As-Is 
process, capture the value added within the process, and analyze and diagnose the current 
NMCI account management process. All of the core sub-processes involved in account 
management were examined and evaluated against one another to determine which sub¬ 
processes provided the least return on the knowledge utilized. It was discovered during 
the initial stages of research that there was no written policy or guidance provided to the 
customer technical representatives (CTR), and therefore, no standardized process existed 
for account management. For the purpose of this thesis, the terms technical 
representative and account manager are used synonymously. 
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1. Data Collection 

The focus of the data collection was to obtain information that would prove 
valuable to understanding the current process for managing accounts before making 
recommendations on improvements. The researcher determined that using BPR 
principles from El Sawy would prove to be most beneficial when defining the current 
process and making recommendations for changes in the process. 

While there was no standardized process for account management across all of the 
USN RC, the researcher expected to find a common, standard process amongst the USN 
RC regions of which a good estimation could be made to perfonn the KVA analysis. 
However, the research found that there was not even a standard process amongst the USN 
RC regions. The scope of the data collection was limited to capturing the current process 
for USN RC account management. It was assumed and verified through phone 
interviews that capturing the account management process for the USN RC would likely 
be a good representation of the process for the United States Navy Active Component 
(USN AC ) as well. 

2. Collection Methodology 

To begin data collection, phone and personal interviews were conducted with the 
Commander Navy Reserve Force Command (CNRFC), Command Infonnation Officer 
(CIO) to identify and prioritize his concerns with the NMCI account management process 
and their effect on the USN RC organization. The purpose of the interviews was to fully 
understand the concerns surrounding account management. The CIO’s concerns were as 
follows: 

• That the U.S. Navy Reserve Component should not be paying for a 
person’s account who is no longer affiliated with the organization due to 
the following status: 

• Deceased, separated, retired, transferred to active duty, etc. 

• That maximum utilization should be made of the two free accounts that 
accompany each unclassified seat; 

• That the U.S. Navy Reserve Component should not be paying for 
duplicate accounts (not to be confused with valid multiple accounts 
required for someone’s job or position); and 
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• That the U.S. Navy Reserve Component should not be paying for an 
account that should be the responsibility of another command outside of 
RESFOR’s claimancy. 

While the interviews with the CIO provided high-level information about the 
USN RC concerns, additional phone interviews were required with the lead of the 
Enterprise Account Management Working Group (EAMWG) to provide more detail 
about the account management process and to understand the business rules better. The 
results of the conference calls provided further insight on the problems within the 
process; the high-level dynamics of the IT systems used for account management; the 
budgeting process for NMCI; and a general overview of some of the major business 
rules. 

A follow-on conference was required with the USN RC CIO and the subject 
matter experts to clarify the account management process. This call made it possible to 
glean information about the vision for the allocation of accounts; the amount currently 
spent on additional accounts (approx. $35M/year) that exceeded the total free accounts 
that accompany a seat; the estimated total of accounts currently not required; the use of 
the Network Enterprise Tool (NET) as the IT solution for account and seat management; 
the use of eMarketplace for budget reconciliation and invoice validation; the role of an 
Assistant, Deputy, and primary Customer Technical Representative (A/D CTR); the 
process for submitting a Move-Add-Change (MAC) request; and how Contract Line Item 
0024s (CLIN 24s) are determined and assigned. 

The results of these meetings required a clearer understanding of how account 
management is accomplished at the Echelon III, IV, and V levels before proceeding. It 
was decided that a visual demonstration of the account management process from 
inception to completion was required to completely understand the necessary actions in 
account management before designing the As-Is process. A visit to the Navy Reserve 
Center (NRC), San Jose assisted in clarifying the numerous sub-processes. The visit 
made it possible to see how the management of accounts was performed, to view the 
required enterprise IT systems, to review the NRC’s process and the IT systems used 
locally; and to capture the estimated time to leam to perform each of the sub-processes. 
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The research concluded that, after seeing the total lack of mandatory standardized 
sub-processes, it would be critical to create a survey to sample a small percentage of 
commands randomly from the different RESFOR regions and various echelons (ECH) to 
understand their approaches to account management. The survey questions are included 
in Appendix B. The survey contained questions that would assist with calculating the 
learning time, the number of core sub-processes that are involved in NMCI account 
management, the time to execute each sub-process, to differentiate between the manual 
and automated sub-processes; and how many times each sub-process is performed in a 
week. A total of thirty-six commands were randomly selected to complete the survey. 
The survey completion sample consisted of the following commands: 

• 1 CTR from CNRFC; 

• 4 Navy Air Commands (3-ECH IV’s and 1-ECH V); 

• 3 REDCOMs (South, Mid-Atlantic, Southwest); and 

• 28 ECH V REDCOM commands (4 ECH V’s for each of the 7 

REDCOMs) 

While the sample size consisted of thirty-six commands, only thirty-three of them 
responded (91.6%). A review of the survey responses concluded that thirty of the thirty- 
three responders provided data that was useable. The survey successfully captured 
account management trends across the various regions; the time to complete each sub¬ 
process; and the learning time involved in each sub-process. 

3. The AS-IS Process 

Infonnation collected during the interviews and surveys as well as observation of 
the process during the site visit made it possible to devise several sub-processes that 
appeared to be common across the regions and formulate them into the As-Is model. The 
purpose was to establish the boundaries between the core scenarios and sub-processes 
and ultimately use the KVA methodology to identify and value the knowledge required 
for each. While the scenarios specifically address DRILLRES and FTS, it is assumed 
that any of these processes pertain to civilian personnel as well. Figures 11-14 depict four 
unique scenarios associated with account management. Note that perforated lines around 
any step of the process indicate that all technical representatives do not consistently 
perform the process. The scenarios are: 
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• Drilling Reservist (DRILLRES) or Full Time Support (FTS) personnel 
reporting to the Navy Reserve Activity (NRA) or from a command not on 
the NMCI network; 

• DRILLRES or FTS transfers from the current command to another 
command that has cutover to NMCI; 

• DRILLRES or FTS depart the USN RC by way of retirement, leaving the 
USN RC for another branch of service; and 

• NRA overall seat and account management process including monthly 
account and asset reconciliation. 

F. “AS-IS” PROCESS FLOWCHARTS 

1. Scenario 1 



Figure 11. As-Is Flowchart When a New DRILLRES/FTS Reports for Duty. 


The first scenario shows the process flow for DRILLRES or FTS personnel that 
are either new to the USN RC or that are transferring from a non-NMCI command. The 
check-in process is as follows: 

1. The User reports to the command for initial check-in. Initial check-in is 
usually perfonned through a command indoctrination process or through 
the manpower department. This process is typically a manual process. 

2. The User in-processes with the NMCI Account Manager 
(ACTR/DCTR/CTR) and the manager make a manual entry to a local 
logbook for tracking purposes. 
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The technical representative annotates the User’s name and rate as well as 
the command unit that the User is assigned in the manual logbook. 

4. Once all new Users are logged, the technical representative will review the 
check-in log and begin to take action. There is normally a significant time 
lapse between when the User was entered into the logbook and when the 
technical representative begins to act upon the log entries (sometimes the 
technical representative will wait until the next business day after a Drill 
Weekend (DWE). In other words, this step in the process is not routinely 
completed while the User is with the technical representative. 

5. The technical representative will look in the Global Address List (GAL) 
for the User’s name annotated in the logbook. 

a. The technical representative contacts the User if one or more 
names are found in the GAL that possibly matches the name of the 
User. Time delay is embedded here, as this process is not 
completed when the User initially performs the check-in process 
with the technical representative. 

b. If one or more of the accounts in the GAL match the User, then the 
technical representative verifies whether those accounts are 
multiple accounts or duplicate (i.e., excess) accounts. 

i. If the account(s) are verified to be a duplicate (or excess), a 
MAC request is submitted to “move” one of the accounts to 
the new command and a request is submitted to “delete” 
any additional accounts. This request is forwarded by 
completing a MS Word template document and sending it 
to the authorized submitter (or DCTR) usually via email. 
The document is then reviewed by the authorized submitter 
(or DCTR) for accuracy and completeness. The authorized 
submitter then forwards it to the NMCI Help Desk for 
action. The help desk forwards a confirmation email to the 
authorized submitter and the initiating technical 
representatives once the request has been completed. The 
initiating technical representative will then make a manual 
entry in the local logbook that includes the new User’s 
account information. 

c. If none of the accounts in the GAL matches the User, a MAC 
request is submitted to “add” the user to the NMCI network. This 
request is forwarded by completing a MS Word template document 
and sending it to the authorized submitter (or DCTR) usually via 
email. The document is then reviewed by the authorized submitter 
(or DCTR) for accuracy and completeness. The authorized 
submitter then forwards it to the NMCI Help Desk for action. The 
help desk forwards a confirmation email to the authorized 
submitter and the initiating technical representatives once the 
request has been completed. The initiating technical representative 
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will then make a manual entry in the local logbook that includes 
the new User’s account information. 


2. Scenario 2 



Figure 12. As-Is Flowchart When an FTS/DRILLRES Transfers. 


The second scenario shows the process flow for DRILLRES or FTS personnel 
that relocate from one command on the NMCI network to another command on NMCI. 
The checkout process is as follows: 

1. The User out-processes with the NMCI Account Manager and the 
manager makes an entry into a manual logbook for tracking purposes. 

2. The local technical representative contacts the gaining command of the 
User to have them submit a MAC to “move” the existing account to the 
gaining command. 

3. The local technical representative waits approximately two weeks to give 
the gaining command time to transfer the command. 

4. At the end of the two-week wait period, the local technical representative 
checks the command’s Active Directory to confirm that the account has 
been transferred. 

a. If the account is still in the local command’s Active Directory, the 
losing command’s technical representative will then submit a 
MAC request to “deactivate” the account. This request is 
forwarded by completing a MS Word template document and 
sending it to the authorized submitter (or DCTR) usually via email. 
The document is then reviewed by the authorized submitter (or 
DCTR) for accuracy and completeness. The authorized submitter 
then forwards it to the NMCI Help Desk for action. The help desk 
forwards a confirmation email to the authorized submitter and the 
initiating technical representatives once the request has been 
completed. The initiating technical representative will then make a 
manual entry in the local logbook indicating that the action was 
completed. 
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b. If confirmation email, which verifies that the action was 
completed, is not received, the losing command’s technical 
representative will continue to check the command’s Active 
Directory for a completed action. A continuation of no action 
prompts the technical representative to contact the authorized 
submitter to check the status of the MAC request. The authorized 
submitter will then contact the contractor Service Request 
Management (SRM) team or the help desk to facilitate the request. 
This process continues until the confirmation email is received 
annotating that the requested MAC was completed. 

3. Scenario 3 




I 


Figure 13. As-Is Flowchart When an FTS/DRILLRES Retires. 


Scenario three illustrates the process flow for DRILLRES or FTS personnel who 
are retiring, leaving military service, or transferring to a non-NMCI command. The 
checkout process is as follows: 

1. The technical representative receives a monthly command 
termination/modification form from the administrative department. 

2. After verifying the User’s status, the local technical representative submits 
a MAC request to “deactivate” the account. 

3. This request is forwarded by completing a MS Word template document 
and sending it to the authorized submitter (or DCTR) usually via email. 

4. The document is then reviewed by the authorized submitter (or DCTR) for 
accuracy and completeness. The authorized submitter then forwards it to 
the NMCI Flelp Desk for action. 

a. No further action required by the technical representative if a 
confirmation email is received stating that action was completed. 

b. If confirmation email, which verifies that the action was 
completed, is not received, the losing command’s technical 
representative will continue to check the command’s Active 
Directory for a completed action. A continuation of no action 
prompts the technical representative to contact the authorized 
submitter to check the status of the MAC request. The authorized 
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submitter will then contact the contractor SRM team or the help 
desk to facilitate the request. This process continues until the 
confirmation email is received annotating that the requested MAC 
was completed. 


4. Scenario 4 



Figure 14. As-Is Flowchart for Allocation of Accounts and Seat Management. 


Scenario four illustrates the process flow for overall management of NMCI seats 
and accounts. This illustration is important to show because is provides a visual flow of 
the various systems that must be used for daily account management. The top process 
flow is for accounts and the bottom is for seats. The processes are as follows: 

a. Accounts 

1. The technical representative counts the number of active accounts that 
exist in the command’s Active Directory. This yields the total number of 
chargeable accounts that should be included on the billing invoice. 

2. Once a month, the technical representative accesses eMarketplace to view 
the monthly invoices. 

3. A comparison is then made with the totals counted from the Active 
Directory and the total number of “free” accounts that are derived from 
each seat to determine the number of CLIN 0024’s required. 

4. The technical representative contacts the contractor to request 
modifications to charges on the billing invoice to reflect the actual 
accounts in the Active Directory. 

b. Seats 

1. The technical representative locally generates a CLIN spreadsheet that 
contains a list of all NMCI hardware and its physical location. This list is 
used to populate the NET database. 

2. The technical representative (or authorized initiator) forwards the 
consolidated list via email to the authorized submitter for review of 
accuracy and completeness. 
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3. The authorized submitter forwards the consolidated list for import of data 
into NET. 

4. A seat identification (SeatID) number is assigned to each piece of NMCI 
standalone hardware. The SeatID is a NET generated number assigned to 
each seat entered into the NET database. Every asset considered a seat in 
NET is assigned a SeatID. Any peripherals attached to a seat do not have 
its own SeatID, but any peripheral that is ordered as stand alone hardware 
is given its own SeatID. 

G. KNOWLEDGE VALUE ADDED IN AN NMCI ENVIRONMENT 

1. Time Required to Learn a Process 

Time and resource constraints dictated the use of the Learning Time methodology 
to calculate the KVA for NMCI account management. In this method, the amount of 
knowledge embedded in a process is represented as the amount of time necessary for an 
average person (i.e., a common reference point, “learner”) to leam how to complete the 
process correctly. Since the researcher was unable to compare results to those of the 
process description or binary query method, the researcher used correlation between the 
nominal learning time (NLT) and actual learning time (ALT) to determine the reliability 
of the estimate: The terms are described below. 

• Actual Learning Time - is the estimated time required for the average 
person to leam each core process. It answers the question of how long it 
would take to train someone to perform each sub-process. It represents 
the value created in each of the sub-process and calculated in the 
numerator of the ROK formula. The ALT numbers were calculated from 
site visits and phone interviews. 

• Nominal Learning Time - is a second estimate of the knowledge required 
to perform the core processes and is obtained from a second source. It is a 
measure of time it takes to learn each sub-process given only 100 total 
hours to complete learning of all sub-processes. For instance, sub-process 
“Create Add User to User Log” requires the average learner to use .5 
hours learning time out of a total of 100 hours. 

Housel and Bell state that the goal of using both estimation methods is to obtain a 
correlation of 80% or higher between them. A lower correlation would indicate one of 
the estimations contains some kind of inaccuracy and will need to be reworked. If the 
numbers correlate well, one could assume some statistical validity between the two 
different estimates obtained from different sources. 
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The data collection to perform the initial analysis can be concluded upon 
gathering the number of command units involved in the overall process (in this case, it is 
the number of command units involved in performing account management); the number 
of people involved in each sub-process per command unit; an accurate count of the 
number of times the knowledge is executed during a sampling period (in this case, one 
week); and the time it takes to execute each core process (called Time to Complete). To 
assist in ensuring that the knowledge estimates are accurate, it is important to avoid 
overestimation —knowledge should only be counted when in use, that is, when it is being 
actively utilized to perfonn a particular sub-process or process. 

2. KVA Calculations 
a. Assumptions 

• Except where noted, all command units utilize the same overall process 
and sub-processes for account management. 

• The number of persons completing each sub-process is an average taken 
from actual survey data. 

• Times Fired is an average number of times that each sub-process was 
completed by a single technical representative in the sample period of a 
week. This average was then converted to number of times fired in an hour 
for purposes of comparability. The data used to derive this average came 
from the surveys. 

• Time to Complete is the average time it took a single technical 
representative to complete one instance of the sub-process. This average 
was derived from survey data. 

To calculate the “benefit” stream for each sub-process, the ALT (hours) 
was multiplied by the Times Fired/hour times the Average # People completing the sub 
process. This provided the number of units of knowledge generated by a single command 
unit for the sub-process for the sample period. This was then multiplied by the total 
number of command units to obtain the total units of knowledge generated by all 
commands for this sub-process. Figure 15 provides a partial illustration of the use of this 
formula in the NMCI process. (J= C x D x F x H) 
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Figure 15. KVA Total Benefits Calculation Example. 


For the purposes of this particular analysis, a surrogate was used for actual 
unit cost due to the difficulty of obtaining actual cost data for so many moving parts 
within the allotted time frame. To estimate this surrogate for unit cost, it was agreed that 
the number of hours that it took to complete a sub-process (Time to Complete) was a 
reasonable equivalent to the actual dollar unit cost since dollar unit cost is the wages/hour 
paid to complete the sub-process. Once a unit cost surrogate was selected, this was 
multiplied by the Times Fired/hour times the Average # People completing the sub 
process and finally by the total number of command units to obtain the total “cost” of the 
knowledge generated by all commands for this sub-process. Figure 16 provides a partial 
illustration of the use of this formula in the NMCI process. (K= C x D x F x G) 
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Figure 16. KVA Total Costs Calculation Example. 


3. Metrics 

In order to glean meaningful insights from the KVA analysis, it was necessary to 
build a performance ratio for the sub-processes. For this ratio, ROK was used. The ROK 
calculation used the standard formula: 


ROK = — 
C 


where: 


K = Knowledge generated by a single core process 

C = Cost assigned to Time to Complete a single core process, or surrogate for cost 
assigned 

The actual calculation for “Create Add User to User Log” is as follows: 

ROK = - 3 ^ 45 -. 

.8625 

This ROK is 400%, meaning that there are four units of knowledge generated for 
every unit of knowledge “cost.” In other words, for every hour that it takes to complete 
this sub-process, it requires four hours of Learning Time. 

Once the ROK ratios for all sub-processes were completed, it was determined that 
they were too inflated to provide helpful insights. Thus, the decision was made to lower 
these ratios by a divisor of 25 throughout, so that more meaningful comparisons could be 


56 























made. Using a common devisor assists with getting the percentages to fall between 1% 
and 100%. Decimal numbers that fall below 1% and any ratios greater than 100% can 
easily be assessed as they standout from the predetennined percentage range. If every 
number in a series is divided by the same divisor, the proportional relationships between 
those numbers remain intact. 

4. Analysis of Results 

To provide an in-depth analysis of the results, some ranges of perfonnance for the 
ROK ratios were established. All sub-processes below 10% ROK were the first line of 
investigation for process reengineering. All sub-processes between 10% and 20% ROK 
were the second area of investigation. Once Categories 1 and 2 were reviewed, the focus 
fell on Category 3 (ROK over 20%) to see whether it was possible to build more 
efficiency or effectiveness here as well. 

Category 1 - ROKs of less than 10%: the amount of automation vs. the amount of 
manual labor involved was examined. Then, the amounts of “wait time” built into the 
sub-processes were reviewed, e.g., did a sub-process require the CTR to wait prolonged 
periods to receive a response. Also investigated were the IT systems used to see if 
streamlining was needed and whether too many systems were required to accomplish a 
given task. It was clear that the sub-processes yielding a less than 10% ROK were heavily 
manual, included long “wait times,” and required multiple inputs into various IT systems. 

Category 2 - ROKs between 10% and 20%: the same methodology as that for 
Category 1 was followed. Note that in this Category, many of the sub-processes were 
locked in place due to business rules that required them to remain in effect. An example 
of this was Sub-Process 5 - REDCOM Approval. All four Category 2 sub-processes, 
with the exception of the REDCOM Approval, were manual sub-processes and could be 
automated without losing valuable data. 

It was also discovered that both Category 1 and Category 2 sub-processes 
included many redundancies that could be consolidated or eliminated by better process 
design. 

Category 3 - ROKs over 20%: Although the returns were high by comparison 
with the other sub-processes, it was noted that the technical representatives were required 
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to utilize several IT systems to accomplish otherwise automated tasks. This meant that 
time was consumed on switching systems that could have been used in producing 
outputs. 

Globally, the ROK analysis made it possible to understand that there was no fully 
integrated central data repository that an “actor” or technical representative could actually 
use to accomplish account management. In addition, it was found that not ah technical 
representative had been trained to use ah the systems they were expected to utilize and 
often technical representative were not even using these systems at ah, whether trained 
for them or not. It was evident from ah these investigations and the ROK analysis that 
serious reengineering of the account management sub-processes was needed. 

Figure 17 shows the complete KVA analysis. 
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KVA As-Is Analysis. 
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The current use of IT was factored into the learning of each of the sub-processes 
as most of these sub-processes are perfonned by entering data into a myriad of electronic 
IT systems or applications. In analyzing the As-Is process, it was concluded that the issue 
was not the lack of IT, but rather the lack of integration between all the different 
electronic systems and applications used to manage accounts. The systems included the 
NMCI Enterprise Account Management Tool (NET) to manage seats but contained 
limited functionality to manage accounts; eMarketplace to validate the monthly billing 
invoices; Service Request Electronic Form (SR eForm) for daily MAC submissions and 
management; MS Outlook for confirmation of MAC submissions and completions; the 
Global Address List (GAL) to verify the establishment or disestablishment of accounts; 
and a multitude of local applications (i.e., locally generated MS Excel spreadsheets and 
MS Access databases) assist in storing all the data gathered from the various systems in 
one location. Active Directory is used very little when perfonning the required monthly 
validation of invoices. 

It is also important to note that not all processes are electronic. Many of the 
technical representatives have created manual logbooks in an effort to manage the status 
of MACs from creation to completion. Also noteworthy is that the SR eForm was not 
fully functional for MAC management at the beginning of this analysis. Instead, the 
ACTRs submitted all requests requiring the contractor’s intervention via email to the 
DCTR, and the DCTR in turn, forwarded them to the SRM team. The ACTR’s inability 
to demonstrate proficiency in using the SR eForm during the site visit was evidence that 
it was not used to manage all MACs, and more importantly, that the users received little 
or no training on its functional attributes. 

The results of the As-Is analysis made it possible to develop a proposed To-Be 

solution for each of the four scenarios previously mentioned. The “To-Be” process flow 

and KVA were detennined and developed by building a demonstrable web-based 

prototype. This prototype website integrated the functionality and processes included in 

the myriad of IT systems previously mentioned. The website also includes easily 

accessible on-line help and training information to the technical representatives. Figures 

18-21 illustrates the recommendations for near-term changes in the current system and 

account management business processes. Each of these corresponds to their counterpart 
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scenario in the As-Is process. As noted by the red outline or the strike through the middle 
of the process or application, several of the current sub-processes will be changed or 
deleted because of the proposed solution. Appendix C provides more information about 
the prototype website and the functionality included. 

H. “TO-BE” PROCESS FLOWCHARTS 

The following figures illustrated the “To-Be” version of the account management 
process flows. The focus will be less on each individual step, since they were explained 
in the As-Is, and more on the changes that have occurred in the process scenarios. Note 
that perforated lines that existed around many of the As-Is steps are now eliminated to 
demonstrate mandatory completion and consistency throughout the USN RC. 

1. Scenario 1 
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Figure 18. To-Be Flowchart When a New DRILLRES/FTS Reports for Duty. 
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The first scenario shows the changes in the process flow for DRILLRES or FTS 
personnel who are either new to the USN RC or who are transferring from a non-NMCI 
command. The changes in the process are as follows. 

• The logbook entry made by the NMCI account manager when the User in¬ 
processes is no longer manual but is now entered into an electronic web- 
based solution. The User enters all information while still physically 
working with the technical representative. Researchers of data quality 
have conducted tests to statistically prove that data-entry errors will be 
minimized if data is entered by its owner. This entry begins the account 
verification process. If other account names exist in the central data 
repository that match the User, the technical representative will receive 
immediate results of any name match and can clarify the account status 
while the user is physically present. The functionality will eliminate the 
time lapse built into the As-Is scenario. 

• The integrated website eliminates the requirement to send the MAC 
request to the authorized submitter to review for accuracy and 
completeness. Entering of required data by the User, and the 
incorporation of form field validation in the website design will ensure 
that the infonnation is complete but does not eliminate the need for the 
authorized submitter to review the request for accuracy. Once the MAC 
request has been submitted by the authorized initiator in the integrated 
web-based system, the request will automatically appear in the in-box of 
the authorized submitter. The authorized submitter can then verify for 
accuracy and submit the request directly to the contractor’s Service 
Request Management (SRM) Team for further action. 

• To achieve efficiency in time and to achieve the maximum use of the two 
“free” accounts that accompany each seat, the integrated web-based 
solution records every seat occupied and unoccupied with the two 
accounts. Any accounts added are automatically assigned the first 
available seat. Any accounts no longer in use are automatically 
unassigned to that seat, and subsequently, account history is automatically 
stored in the database. This history allows for the instant retrieval of 
account User data when a new account name matches any that exists in the 
history file or table. This eliminates the creation of duplicate accounts and 
would only require re-activation of an account that may have been placed 
in an inactive status. 
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2 . 


Scenario 2 



Figure 19. To-Be Flowchart When an FTS/DRILLRES Transfers. 


The second scenario shows the changes in the process flow for DRILLRES or 
FTS personnel that relocate from one command on the NMCI network to another 
command on NMCI. The changes in the process are as follows. 

• Just as in Scenario 1, the logbook entry made by the NMCI account 
manager when the User in-processes is no longer manual but is now 
entered into an electronic web-based solution. 

• The technical representative can then automatically unassign the User 
from the occupied seat by initiating an account transfer from the losing 
command to the gaining command. Initiation of an account transfer by the 
local technical representative will automatically submit an account transfer 
request to the in-box of the gaining technical representative. Automating 
this process eliminates the need to inform the gaining technical 
representative that an account transfer is required. Submitting the request 
does not eliminate fiscal and management responsibility by the local 
technical representative until the account has been accepted by the gaining 
command via the integrated web-base tool. 

• Management oversight by the technical representative is still required to 
ensure that the account is removed from the local Active Directory. This 
requirement does not eliminate the account transfer verification loop that 
is included in the As-Is, but it does eradicate the requirement to submit the 
MAC request via email to the authorized submitter. 
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3. 


Scenario 3 



Figure 20. To-Be Flowchart When an FTS/DRILLRES Transfers. 


Scenario three illustrates the changes in the process flow for DRILLRES or FTS 
personnel retiring, leaving the military service, or transferring to a non-NMCI command. 
The changes in the process are as follows. 


• The integrated web-based data repository eliminates the need for the 
technical representative to complete the MS Word document and submit 
the MAC request to the authorized submitter via email. Once the request 
is entered in the web-based tool, it is automatically sent to the authorized 
submitter and awaits action in the in-box. 
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Figure 21. To-Be Flowchart for Allocation of Accounts and Seat Management. 


Scenario four illustrates the changes in the process flow for overall management 
of NMCI seats and accounts. The scenario illustrates that most of the sub-processes 
included in the As-Is are now modified to include the use of the web-based integrated 
central data repository with NET and eMarketplace. Again, the top process flow is for 
accounts and the bottom is for seats. The changes in the processes are as follows. 
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a. Accounts 

• Initially, the technical representative would ensure that all current NMCI 
users are entered into the integrated web-based management tool. By 
using automated reports that could be generated and exported from the 
web-based tool, the technical representative would perform a comparison 
between the active accounts in the Active Directory and the system 
generated report. Any disparities or MAC requirements would be 
submitted directly through the integrated web-based tool. There would 
not be a need to compare the Active Directory numbers manually to the 
“free” seats to determine CLIN 0024s as the account-to-seat allocation 
would be system generated. Likewise, the system would automatically 
calculate any account requirements that exceeded the “free” accounts that 
accompanied each seat by providing a sum total of required CLIN 0024s. 

• The web-based tool is sophisticated enough to generate a report that 
contains accumulated seat and account data with similar data output fields 
that exist in eMarketplace. This would enable the technical representative 
to generate a report through the web-based tool and compare it with the 
eMarketplace invoice. 

b. Seats 

• Ensuring that actual seat data match what exists in NET since NET is 
currently the management tool of choice. The integrated web-based tool 
allows technical representatives to perfonn a physical inventory of their 
existing assets, enter the findings in the web-based tool, and provide an 
interface with the NET seat module to provide easy and automated import 
of data between the systems. The interface between the prototype web- 
based tool and NET would eliminate the requirement to submit any 
modifications via a spreadsheet to the authorized submitter. 

5. Data Analysis Comparison 

The principles of KVA and BPR were used to recommend modifications and to 
achieve efficiencies in the account management process. It was decided that addressing 
the ROKs that met the criteria for Category 1 above would provide the most immediate 
return as manual processes would be automated thus decreasing the time to complete the 
sub-process. Additionally, the desire was to capture as much knowledge in the heads of 
people and embed it in the IT system when feasible. The numbers included for the “To- 
Be” Time to Complete and the Actual Learning Time are based on the testing and 
evaluation of the prototype web-based solution, and not just professional judgment. 

While adding automation did eliminate most manual processes, it also required 
additional sub-processes to compensate for the automation. The KVA shows an increase 
in the ROK in several of the sub-processes. The ROK increase is attributable to an 
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increase in knowledge embedded in the IT systems, as smarter IT systems require less 
knowledge of the process in the minds of the account management actors, to the merging 
of several processes into one, the elimination of manual sub-processes, and a decrease in 
the time to complete each of the remaining sub-processes. The following sub-processes 
were eliminated with the use of automation and system integration: Fill out Request 
Document (MAC) in Word (sub-process row #5) and Aggregate CLIN spreadsheet sent 
to NET website (sub-process row #19). These sub-process rows are highlighted in grey 
in Figure 22. As previously mentioned, the following sub-processes were required to be 
added because of automation and system integration: Fill out Electronic Log Request 
(sub-process row #4); Verity Unit Information and submit rapid request (sub-process row 
#8); and Track Equipment Purchases through the new web-based site (sub-process row 
#18). These sub-processes have a red font color and have a grey highlight in the “Before 
(from As-Is)” column (column L). 

The remaining sub-processes with red font color within the numbers represent 
those that have been modified with the use of an integrated and automated central data 
repository. While many interpretations can be made from the data, the data analysis for 
this section focuses only on the increases or decreases to the Time to Complete, which 
affects increases or decreases to the proxy “cost” discussed in Section C of this chapter. 
In other words, the analysis focuses on how the process changes improved the benefit 
stream and/or the decreased the proxy costs. This is done by comparing the Time to 
Complete from the “To-Be” to the Time to Complete from the “As-Is”. These processes 
include the following. 

• Review User Log and Check for existing account (sub-process row #6). 
Since this sub-process will be automatically performed through the 
integrated website, through testing and evaluation, it was determined that 
automation would yield a decrease in the Time to Complete from 0.05 
hours to 0.03 hours. The analysis of the data concluded that the 
percentage of time to complete was decreased by 40%. 

(0.03-0.05) Q/| 

0.05 

Similar comparisons will be made with the remaining processes that have been 
changed. 
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Ask User about need for multiple accounts (sub-process row #7). This 
sub-process will no longer allow the technical representative to wait until 
after a drill weekend to contact a NMCI user, but will enable him to ask 
the user at the time the new NMCI account is requested. Using the same 
comparison methodology as the previous sub-process, it can be concluded 

(0.03-0.5) 


that the Time to Complete was decreased by 94%. 


0.5 


= -.94 


Assign/Unassigned User to seat in our Site (sub-process row #12). This 
sub-process eliminates the need for the technical representative to perform 
unused seat-to-account mapping in their local tracking system (from As-Is, 
Figure 17, sub-process row #10). The use of automation and system 
integration automatically finds the first available or unused seat and 
performs user-to-seat mapping as they are entered. Data analysis yields a 

75.7% decrease in the Time to Complete. ^ ^ = -0.757 

0.33 


Contact User’s Prospective Command (sub-process row #15). Great 
efficiency is achieved in this area by using the prototype tool as the 
process of transferring and the account is mostly system generated. This 
increases the number of times this process can be completed in an hour 
and decreases the overall time to complete one instance of the sub-process. 
Analysis of the data concludes a 94.4% decrease in the completion time. 
(0.083-1.5) 


1.5 


= -.944 


• Look up Invoice Page on eMarketplace (sub-process row #16). Since all 
of the data will be integrated into the web-based tool, the technical 
representative is required only to generate a report and complete the 
verification. Automating this process drastically decreases the Time to 

Complete by 83.3%. —^ — = -.833 

KVA provides the data analysis with many options for data comparison within the 
sub-processes or with overall ROK percentages. The numbers in the spreadsheets listed 
previously represents a relative comparison between the ROK for the As-Is and the To- 
Be processes. A relative comparison between the overall ROK totals yield a 6.95% 
increase in overall efficiency (31.70% - 24.75%=6.95%). 
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Figure 22. KVA To-Be Analysis. 


I. CHAPTER SUMMARY 

This chapter began by providing detailed information on the theory of Knowledge 
Management. The definition of Knowledge Management was provided and can be 
summarized as a set of activities aided by IT designed to help organizations to create, 
capture, synthesize, deploy, share, preserve, and reuse organizational knowledge more 
effectively. The section on BPR addressed its phases as defined by El Sawy. The 
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evolution of Knowledge Management has constituted what is considered the “second- 
wave” BPR, which focuses on effectively managing knowledge around business 
processes. The chapter demonstrated how the process redesign heuristics and the KVA 
methodology was used to increase the knowledge-creating capacity of the account 
management process so that it learns more effectively through the interactions of its 
various participants. 

KVA methodology was also used to measure the ROK as a way of comparing 
how much value different BPR alternatives provide to the account management process. 
BPR emphasizes the importance of creating value quickly and value can be created 
through increased knowledge creation around processes. Developing a web-based 
prototype enabled the testing and evaluation of BPR alternatives and was used to 
calculate the To-Be process flow for the various defined scenarios. The KVA 
methodology uniquely enabled the ability to capture and quantitatively measure the 
amount of knowledge as a common unit of output that exists in each of the sub-processes 
in managing NMCI accounts. This could not have been accomplished solely with the use 
of BPR principles. Quantitatively capturing the knowledge, in units of learning time, 
allowed relative comparisons of the sub-processes and the ROK to be made. 

The next chapter provides an analysis of what industry considers successful 
measures for outsourcing and seat management. It also examines commercial companies 
that have outsourced their IT resources and the business practices implemented that led to 
their success. The second half of the chapter reviews best-of-breed COTs tools used by 
industry to perform enterprise-wide seat management. 
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V. INDUSTRY STANDARDS FOR OUTSOURCING AND 
COMMERCIAL-OFF-THE- SHELF MANAGEMENT TOOLS 

A. INTRODUCTION 

Researchers have documented that information technology (IT) outsourcing has 
increased enormously over the past decade. This increase has required that outsourcing 
organizations create and codify standards and best practices that promote sharing 
strategies and ensure tangible, sustainable results. This chapter discusses some of these 
strategies based on research conducted by Gartner Inc. and other outsourcing researchers. 
Included in the chapter are industry best practices for administering and managing 
information technology (IT) outsourcing contracts. 

Previous chapters discussed the lack of an integrated IT solution and its impact on 
Navy Marine Corps Intranet (NMCI) management. This chapter assesses “best-of- 
breed” commercial-off-the-shelf (COTS) products used by industry, which could also be 
used as an enterprise IT solution for NMCI management. 

B. INFORMATION TECHNOLOGY OUTSOURCING BEST PRACTICES 

Many enterprises, or service recipients (SR), have decided to outsource all, or a 
portion of their IT functions to increase value and add benefits to the organization. 
William Maurer of Gartner Research states that some of these benefits are that the 
organization is allowed to concentrate on core competencies; speed to market is 
enhanced; change management initiatives are improved; and costs are lowered [Ref. 24]. 
While IT outsourcing has gained tremendous popularity in today’s business environment, 
more than half of all outsourcing arrangements fail to deliver the expected benefits or 
value [Ref. 25], This failure has been attributed to mismanagement of outsourcing 
endeavors from the establishment of the sourcing plan to the management of the contract 
after it is awarded. The following sub-section discusses the widely-accepted four phases 
of strategic outsourcing. While there are many forms of outsourcing deals, a phased- 
approach, focused on IT utility sourcing contracts, will be discussed since it is relevant to 
the NMCI environment. 
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1. Four Phases of Strategic Outsourcing 

Gartner Research has studied the behaviors and practices of outsourcing strategies 
as well as its methodologies. They have recognized that most organizations lack the 
skills required to manage the outsourcing relationship with external service providers 
(ESPs) once it has been established [Ref. 26]. To assist with the process, Gartner states 
that decision-makers need to carefully craft their strategic outsourcing plans to allow for 
“partnerships” with their ESPs. These partnerships will enable businesses to become 
more agile with their customers and the changing requirements of the organization [Ref. 
26]. Establishing a partnership is not something that occurs suddenly, but should be 
revealed by using an evolutionary approach, which Gartner refers to as the four phases of 
strategic outsourcing process. The phases of the strategic outsourcing process shown in 
pictorial form in Figure 23 are: 

• Sourcing Strategy 

• Evaluation and Selection 

• Contract Development 

• Sourcing Management 

This process has become the industry standard for outsourcing as it takes 
enterprises from the initial decision, to strategic outsourcing, and through ongoing 
management of the partnership during the life of the contract. The process considers 
future objectives, new opportunities, and the potential for change [Ref. 26]. 


Figure 23. 



' Sourcing 
Manngnmocit 


Sourcing 
Sira logy 


“ Contract 
.Development 


Eradiation 
& Selection 


Strategic Sourcing Process (From: Ref. 26). 


a. Phase 1: Sourcing Strategy 

Phase 1 begins with the questions of business strategy and goals. 
Knowing the goals and direction of the organization enables senior leadership to 
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determine which services would be handled most effectively through outsourcing. 
Jennifer Beck, Gartner Research analyst, states that most organizational leadership agree 
that one of the biggest challenges in outsourcing is aligning IT with the business strategy 
[Ref 27]. 

During this phase, organizations should carefully define and closely 
analyze their enterprise and evaluate the risks and benefits of outsourcing. They should 
clearly understand what is required in the final contract at award and consider what is 
preferred throughout its duration. Selection of vendors should be cautiously made as any 
outsourcing partnership formed solely on present circumstances is not thinking 
strategically and could be doomed for failure. Vendors should also be selected based on 
their ability to meet the strategic goals of the organization. This will establish a context 
for well-timed future success. 



Figure 24. Phase 1: Sourcing Strategy (From: Ref. 26). 

b. Phase 2: Evaluation and Selection 

Phase 2 empowers senior leadership to define its requirements and identify 
potential partners that can meet the organization’s business needs. Organizations should 
evaluate potential service providers by establishing guidelines regarding contract 
flexibility and cooperative decision-making that will govern the final contract. A 
decision framework for evaluating and selecting vendors is also included in this phase of 
the strategic sourcing life cycle. 

There are several ways that vendors can be selected but two of the more 
popular means is through Request for Proposal (RFP) and Single-Source. 

Gartner Research states that soliciting vendor interest by using the RFP 
approach “invites about five to twelve service providers to respond to the requirements 
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stated RFP. It then attempts to uncover key differences among the service providers” 
[Gartner Research in Ref. 26]. The negative aspect of this approach is that service 
providers submit boilerplate responses as a result of cost-of-sale and opportunity-to-win 
concerns among the many respondents. The RFP approach usually requires the longest 
timeframe and more is expensive than the Single Source approach. 

The Single Source approach invites one service provider to develop an 
offer. Selecting a vendor using this approach is usually driven by an existing relationship 
the vendor may have with the organization. In government organizations, the single 
source approach must be accompanied with justification. It is often used when there is a 
need for unique skills, tools, or technology. Services that are limited by time constraints 
also warrant the use of the single source approach. Although this approach may seem to 
shorten the negotiation process, it can also lengthen it or establish an inequitable 
agreement when the service provider desires certain contract terms and when the service 
recipient is anxious to close a deal [Ref. 26]. In addition, the lack of competition among 
service providers can also remove incentives for the selected provider to offer the 
purchasing organization the best terms and services. 

Realistic expectations about costs and service benefits should also be 
realized during this phase. Gartner believes that only when a decision is made on these 
elements can the search for a service provider proceed successfully and efficiently. 



Figure 25. Phase 2: Evaluation and Selection (From: Ref. 26). 
c. Phase 3: Contact Development 

Phase 3 assists users in constructing the proper contract based on their 
needs and negotiating the appropriate deals with the vendor. In this phase, the SR and 
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service provider (SP) structure a flexible partnership with defined service levels and 
payment models by negotiating a realistic and effective contract. “Hammering out the 
details of performance measures and terms that are flexible enough to withstand changes 
during the course of the partnership is crucial” [Ref. 26]. Many IT outsourcing contracts 
were awarded based on misunderstandings about cost. The initial costs may look 
appealing because surcharges are buried in the details for later years and the cost of 
managing the partnership over time is rarely taken into consideration. 

Performance measures must be made clear and a realistic assessment of 
the true costs in the contract must be made. Equally important, the contract terms should 
be flexible enough to withstand the inevitable changes that take place during the course 
of a partnership. 



Figure 26. Phase 3: Contact Development (From: Ref. 26). 

d. Phase 4: Outsourcing Management 

The fourth phase involves project management once the contract has been 
awarded. Since the outsourcing process does not end after the contract is signed, the 
partnership between the SR and SP must be maintained as a living, breathing entity. It 
must be monitored and nurtured to ensure that the conditions of the contract are met and 
modified as the business requirements change. As shifts in capacities, needs and 
opportunities to innovate occur, the partnership should use benchmarking to make sure it 
is aware that change is taking place. To foster a healthy working relationship, both 
parties must consider these changes when reassessing the terms of the contract. Gartner 
believes that this is the only way to keep the partnership fresh and alive. 
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Figure 27. Phase 4: Sourcing Management (From: Ref. 26). 

There are many ways to detemiine whether the SP is providing an 
organization the service it desires and meeting its expectations in a sourcing contract. 
Industry has defined some of these as qualitative determinants and some can be measured 
quantitatively. The focus of the research in the following sub-sections includes two well- 
known quantitative approaches to measuring contract performance, benchmarking and 
service-level agreements. It is believed that these two approaches provide the most value 
to an enterprise. 

2. Benchmarking 

Today’s business requirements dictate that organizations be flexible and possess 
an ability to change at a moment’s notice and that change must be institutionalized 
quickly and effectively. Benchmarking is one of a number of quantitative approaches to 
ensure that an organization and the SP are maintaining the agreed upon levels of 
organizational change and are prepared for possible reevaluation of contractual courses of 
action. 

When defining the requirements of the IT resources to be obtained through 
outsourcing, it is not practical to set absolute standards for performance in an 
environment of continual change. A common alternative is benchmarking. 
Benchmarking is defined as a minimum industry based standard that must be met and 
serves to take into account changes in technology [Ref. 28]. It is a way for the SR and SP 
to validate their relationship and prove SP value over time [Ref. 24]. Setting benchmarks 
for the requirements not only accommodates technology advances, but also allows for 
monitoring contractor compliance with the requirements to keep up with technological 
changes [Ref. 28]. 
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For SRs seeking to understand how well their sourcing relationship is perfonning, 
a comprehensive benchmarking program can be critical to the continuing success of the 
outsourcing relationship. Identifying and monitoring areas of strength and weakness 
facilitates a proactive dialogue between an SP and its SR and helps ensure that the 
strategic goals of the SP and SR are known, aligned, and remain achievable during the 
course of the relationship [Ref. 24], In the benchmarking process for an outsourcing 
engagement, the SP price and SR retained costs are combined and compared to a peer 
group of organizations with similar complexities and workloads. A process is put in 
place to ensure the peer groups selected are truly comparable and the quantitative 
comparisons developed are defensible. William Maurer et al. state that this process is an 
assessment of risk transfer that is accepted by the SP at the time the two parties engaged 
in the relationship during Phase 3 of the Strategic Sourcing process. The risk transfer in 
most outsourcing contracts consists of items such as responsibility and control; service- 
level agreements; and contractual recourse through penalties. 

William Maurer indicates that an SR/SP benchmark must place a value on these 
risk transfer elements and ensure that they are accounted for in peer group comparisons 
[Ref. 24]. Assigning value and accountability can occur in one of two ways: “the peer 
group can consist of similar outsourced engagements, or a peer group of organizations 
with similar workloads and complexities” [Ref. 24]. Once a valid peer group is identified 
with the appropriate level of risk transfer factored into the equation, the comparison of 
price plus retained costs can be made. Using these comparisons will likely reveal 
opportunities for improvement, illustrate where the relationship falls according to 
industry comparisons, and provide the SR with a level of awareness on whether they are 
getting the most ‘bang for their buck.’ 

Outsourcing theorists believe that benchmarking can change the relationship and 
the pricing strategies between the SR and the SP. While benchmarking provides a 
marketplace price and service comparison, it also provides a certain level of comfort that 
any the long-term agreements will remain aligned with the market conditions. The 
rapidly changing IT environment requires the consideration of annual benchmarking to 
ensure that the pricing and services are also modified with the changes in the marketplace 
conditions. 
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3. Service-Level Agreements 

As the number of organizations outsourcing IT functions continues to grow, these 
organizations are constantly seeking ways to reduce cost and improve service in their 
outsourcing endeavors. One of the lessons learned from outsourcing is the critical need 
to establish performance monitoring and have the right service levels, both of which are 
considered subsets of performance management. This provides visibility into the SP’s 
performance, ensures that service levels support the continuous attainment of business 
objectives, and drives the desired SP behavior [Ref. 30]. Performance management is 
broadly defined as “the activities and processes needed to determine if the contract is 
being satisfactorily executed” [Ref. 29]. More specifically, it is the process of monitoring 
vendor performance against the contractual requirements. 

Performance management can be categorized as either strategic or tactical. 
Strategic performance management is concerned with higher-level organizational goals 
including overall costs, schedules, and performance goals. Conversely, tactical 
performance management is concerned with the SP’s performance against the specific 
itemized services. For this reason, tactical performance management is routinely 
categorized as “service level performance management.” [Ref. 29] 

Performance measures are commonly used to detennine whether a SP is meeting 
the performance standards established in the contract. These measures can be both 
quantitative and qualitative. However, the most effective measures are quantitative. By 
definition, performance measures should be specific, objective, and verifiable to 
minimize the opportunity for dispute. Additionally, they should include only items that 
are the sole responsibility of the SP, to minimize disputes pertaining to task ownership. It 
is often beneficial to bind incentives and/or penalties to the perfonnance measures. This 
emphasizes their importance to the organization while encouraging the SP to exceed the 
organization’s expectations. 

Many IT contracts include perfonnance measures ingrained in the description of 
service levels and defined and managed through the use of service-level agreements 
(SLAs). A SLA is defined as a “contractual tool keyed to the customer’s expectations” as 
SPs and organizations decide which services will be provided and what will be the 
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criteria for measuring their success and failure [Ref. 31]. In essence, a SLA is a 
contractual commitment to meet specific goals and includes a pre-defined perfonnance 
monitoring methodology. The advantages associated with incorporating SLAs into an 
outsourcing contact include providing the organization and the contractor with a baseline 
to measure performance, and establishing a method for allowing payments (via incentives 
and/or penalties) to be tied to performance, service quality, and customer satisfaction. 

William Maurer et al. have stated in their research that the foundation of 
incentives and penalties lies within the service-level agreement (SLA) portion of the 
outsourcing contract [Ref. 32]. They further state that “Service-levels should be set to the 
minimum acceptable level of perfonnance required to meet the enterprise business 
objectives. For the service levels to qualify as an SLA and, therefore, an effective 
foundational tool for managing the outsourcing relationship, the service levels — when 
not met by the ESP — must be subject to contractual penalties.” In their research, they 
indicate that IT management best practices dictate that service levels must meet the 
criteria of a five-step process to qualify as a valid and usable measurement tool. The five- 
step process is: 

• Define the required service levels to ensure maximum effectiveness and 
meet minimum business objectives. 

• Measure service activity results against the defined service levels. 

• Examine the results for problem detennination and root cause analysis. 

• Take appropriate corrective action. 

• Continuously guide service activities to hold the gains achieved by the 
corrective action taken. 

While a variety of performance measures can be used, basic measures should 

cover vendor response time, system availability, and system downtime. Also, to be 

effective, SLAs should be developed with a focus on such areas as completeness, 

reporting functions, change management, and consistency [Ref. 33]. Completeness refers 

to outlining all of the functions that are monitored. A common error in writing SLAs is 

specifying too many services to measure. It is important to note that every service or 

function does not necessarily require its own SLA. An effort should be made to measure 

those services and requirements that are deemed critical to organizational success and 

those that provide the most value to its customers. This objective is met by consolidating 
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requirements and measurable services so the total number of SLAs is as low as possible 
without eliminating or overshadowing the critical requirements. 

Reporting functions include reports that are used to judge performance, how 
frequently they are generated, and who will receive them [Ref. 33]. The two categories 
of reporting for SLAs are real time reporting and periodic reporting. The purpose of real 
time reporting is to allow clients to know the status of the service or network. Prompt 
notification should be provided to the organization when problems occur. This 
notification should include the cause of the problem, the impact, and the plan for 
resolution. Periodic reporting (most common in SLAs) refers to historical metrics on 
actual service performance that are then compared to the contract requirements. 

Change management involves considering the dynamics that accompany any IT 
network project and require portions of the contract to be amended or adapted to address 
ongoing change. In a network environment, hardware, software, and users are frequently 
added, deleted, or modified. The SLAs should identify how such changes will be 
considered in the performance requirements and performance measures. 

Consistency addresses the idea that SLAs tend to be complex and lengthy; 
therefore they should be written to ensure that common terms are used in a consistent 
manner both within the SLA and across the enterprise to achieve semantic harmony. 

Maurer, Scardino, and Young have written that to develop a set of effective 
business-based service levels, organizations must use a prescribed service-level selection 
methodology based on clarity, rigor, and consistency. The selection methodology 
includes: 

• Functions - defining functional categories that will be measured. This 
section should include any production support required to ensure that the 
system produces the expected results. Also included are user support 
activities to ensure questions are answered, and problems are researched 
and user assistance is provided. Lastly included in this section are 
maintenance and enhancement requests. 

• Activities - clearly describing activities in the functional categories 
mentioned in the Functions category. The Activities section provides 
greater technical and measurable detail for each area. 

• Service-level components - identifying common service levels seen in 
various outsourcing engagements 
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Gartner has developed a list of the 100 most common service levels used by 
enterprises. The following is an example of how a SLA for Customer Satisfaction might 
be developed. [Ref. 32]. Table 2 provides an illustration of completed descriptions of 
several service levels that apply to Customer Satisfaction [Ref. 30]. 

• Category: Customer satisfaction — ongoing 

• Explanation: Measures performance of a specific function, such as help 
desk call resolution or desktop problem resolution. Explanations are used 
to identify end user's opinion of service perfonnance. The results are used 
to identify and resolve any issues and problems. The resulting actions 
should improve end-user/management satisfaction and service 
performance. 

• Service level: Establish that 92 percent are very satisfied or satisfied, ft is 
important to note that the customer satisfaction process will not start until 
six months after contract initiation and project/activity initiation. 

• Responsibilities: Measure customer satisfaction on a daily basis by taking 
less than 5 percent of daily activities and completing a customer 
satisfaction record per documented processes and procedures. The 
sampling should be spread over the various functional areas. 

• Assumptions: Survey will be completed via direct voice contact or via e- 
mail. End users will take part on a volunteer basis. 

• Measure formula: The following formula is valid for the daily and 
monthly reporting periods: The number of responses with a “very 
satisfied” or “satisfied” rating divided by the total number of responses 
equals the percentage service level attained. 

• Data sources: An ESP-provided tool that provides documentation 
capabilities will be used to meet the reporting requirements. 

• Incentive or penalty fonnula: Variable 
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Category 

Requirements 

Quality 

Service Level 

Measurement Formula 

Application 
break'fix 
Priority 1 

Restore 
functionality of 
critical 
applications 

Less than 2 
oercert rework 
after completion 
and 

mplementat on of 
fix 

Two business 
hours resolution 
for on-shift 98 
percent of the 
time. Twelve 
business hours 
resolution for off- 
shift 93 percent 
of the time 

Time that the critical 
application is down, beginning 
with notification and ending 
with user acceptance. 

Downtime less than or equal to 
two hours equals SLA met. 
(Weight factor plus all other 
downtime incidents divided by 
the total number of incidents 
must be greater than 9e 
percent.) 

Application 
break'fix 
Priority 2 

Restore 
functionality of 
tne applicator 

Less than 2 
oercert rework 
after completion 
and 

implementation of 
fix 

4S business 
hours resolution 
for on-shift and 
off-shift 94 
percent of the 
time 

Time that the critical 
application is down, beginning 
with notification and ending 
with user acceptance. 

Downtime less than or equal to 
48 hours equals SLA met. 
(Weight factor plus all other 
downtime incidents divided by 
the total number of incidents 
must fce greater than 94 
percent.) 

Application 
break/fix 
Priority 3 

Restore 
functionality of 
tie applicator 

Less than 2 
percent re-work 
after completion 
and 

mplementat on of 
fix 

Seventy-two 
business hours 
resolution for on- 
shift and off-sh ft 
9C percent of the 
time 

Time that the critical 
application is down, beginning 
with notification and end ing 
with user acceptance. 

Downtime less than or equal to 
72 hours equals SLA met. 
(Weight factor plus all other 
downtime incidents divided by 
the total number of incdents 
must fce greater than 90 
percent.) 


Source: Gartner Research (November 2004) 


Table 2. Service-Level Examples (From: Ref. 26). 


4. Successful Organizational Outsourcing Engagements 

Many articles have been written to highlight unsuccessful outsourcing deals, but 
less fanfare is given to the successful ones. The following subsections describe two 
successful IT outsourcing partnerships and provide infonnation regarding key factors in 
their success. 

a. City of Chicago Partner with Unisys and Acxiom 
With a newly elected mayor leading the charge, the City of Chicago 
wanted to make some changes in its business practices to increase its effectiveness for its 
citizens and efficiency in its operation. The Mayor was looking for non-strategic services 
that would be a prime candidate for outsourcing so that its employees could focus on core 
business processes. At the request of the Mayor, Gartner conducted an IT user 
satisfaction study to establish a baseline of how well its internal IT resources were 
providing IT services [Ref. 35]. The City’s score of 2.87 on a scale of 5.0 confirmed that 
the City was performing less than satisfactorily and fell below the industry average 
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benchmark of 3.56. This score illustrated that establishing an IT outsourcing partnership 
to manage the City’s key IT functional areas and assets could provide significant value to 
the City’s strategic objectives. 

The City of Chicago partnered with Unisys and Acxiom to increase 
service levels for its customers and to assist with controlling costs. Acxiom was 
responsible for the mainframe outsourcing and the related functions such as tape and disk 
storage subsystems, database support and batch and online application management. 
Unisys acquired oversight for help desk support, desktop and network management, and 
asset management and maintenance. Unisys’ direct contact with end users required the 
company to demonstrate that it could improve the customer satisfaction rating as well as 
the service levels [Ref. 35]. 

This commitment to improvement by Unisys was evident in its aggressive 
approach and unparallel concentration to improve its services to the City. The 
partnership began to reap the benefits that accompany IT outsourcing deals quickly as 
Unisys established a centrally managed helpdesk where all the problems or services are 
received and a follow-up and feedback loop for all helpdesk support, and constructed an 
on-site team to provide desktop, application and network support. Additionally, they 
created a Program Management Office for management of on-site personnel and for 
addressing any outstanding issues that may arise from key city officials [Ref. 35]. 

Acxiom implemented hardware migration and consolidation efforts and 
relieved the City of their print and mail responsibilities. They gained responsibility for a 
host of other IT functions that were perfonned by the City of Chicago staff. 

These modifications, along with the additions and modification made by 
Acxiom, enabled the City of Chicago to realize exponential improvements in customer 
service and customer satisfaction. A follow-up survey revealed that 80 percent of the 
respondents were satisfied with the improved service-level. Additional benchmarking 
was perfonned to provide quantifiable measures on perfonnance and outsourcing 
services. 

The Mayor credits the success of this partnership to several critical 

success factors and lessons learned [Ref. 36]: 
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• With an outsourcing agreement, the organization must set reasonable 
expectations and not sell the outsourced services as a panacea that will fix 
all of the problems quickly. 

• Develop strength around contract vendor management. The retained staff 
members need different skills to manage the outsourced contracts than was 
required internally to manage employees and address operational 
problems. 

• Incorporate end users in the process from the beginning, but expect and 
accept resistance to the change. 

• The vendor use of an on-site project management team is helpful and can 
ease the transition process. 

• Use service-level agreements that are focused on time, cost and quality, 
such as closed call time, end-user satisfaction and network/application 
performance. 

• Develop a contract that encourages gain sharing. If the vendor can bring in 
new innovation and agree to share some of the cost savings. 

• Cultivate CEO-level support. It is essential that the top executive be 
committed to the outsourcing effort to ensure enterprise cooperation. 

• Pick vendors that will be long-tenn partners. If the vendors are not 
committed to working with the organization as a partner, the relationship 
will become a deal without flexibility and will grow stagnate over time. 

b. Nike Partner with Lockheed Martin 

Nike and Lockheed Martin developed an outsourcing partnership in April 
1999 where Nike would relinquish management and ownership responsibilities for its 
internal Corporate Information Technology services [Ref. 34]. Nike desired to outsource 
its Information Technology (IT) services at a time when it was decreasing in market- 
share so the creativity and talent of its personnel could ultimately focus on the core 
athletic businesses while enhancing competitiveness through greater focus on product 
superiority and customer service. These services include desktop support, data center, 
network management, help-desk services, and technical asset management operations. 

Bert Liverance, Director Global IT Operations for Nike, indicated that the 
key to the success of his Nike’s outsourcing endeavor was realizing that a good 
outsourcing relationship takes work. As the relationship matures, periodically it makes 
sense to take the time to evaluate the perfonnance and objectives of your partnership. 
Check the alignment and all the vital connections. For no matter how good the 
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relationship is, there is always room for improvement. Timely identification of these 
opportunities helps to ensure a strong ongoing relationship [Ref 34]. Liverance further 
attributes the partnerships success to development of a process to evaluate and 
benchmark the outsourcing relationship to drive performance improvements. By 
realizing that any relationship will not reach perfection at its inception, both parties 
agreed that a procedure to detennine and measure the qualitative and quantitative 
characteristics of the relationship was necessary. Finally, as Nike’s business 
requirements changed, the partnership and certain aspects of the contract needed to be 
dynamically li nk ed to prevent stagnating Nike’s competitive edge. 

C. COMMERCIAL-OFF-THE-SHELF APPLICATION ANALYSIS 

The increase in the use of IT systems and web-based technologies has forced 
organizations to change the way they conduct business. They must now find new ways 
and new tools to control access to organizational resources securely. Additionally, 
organizations must be able to manage increased security risks associated with the 
escalating volume of user administration. To succeed in these areas, a comprehensive 
and integrated security solution must be built into their networking strategy. 

While there are many applications and resources that can assist in building a more 
secure network, an Identity and Access Management (IAM) solution is believed to be 
ideal for use in minimizing duplicate accounts, the need for multiple accounts, and thus 
increase CLIN 0024’s in the Navy Marine Corps Intranet (NMCI) networking 
environment. Enterprise IAM can be defined as a set of processes and technologies to 
manage user objects more effectively and consistently over relatively large numbers of 
systems and directories [Ref. 36], When fully integrated with the network, an enterprise 
IAM solution is best as it eliminates multiple accounts by assigning multiple user 
identities and roles to a single account. It also enables administrators to establish security 
settings to disallow the creation of a duplicate account based on the user’s credentials. 
The enterprise IAM solution has a host of other functionalities that will not be mentioned 
in this thesis, but should be reviewed to appreciate and gain full benefit of the power this 
solution possesses. 
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1. Overview of Identity and Access Management 

Identities are pieces of information that identify a user’s existence [Ref. 37]. To 
allow users to utilize and benefit from the many applications and services offered, 
organizations of all types assign identifiers, or unique codes, to individuals in order to 
represent their uniqueness to the organization and easily map to applications and services. 
Individuals take on multiple roles using these identifiers as their digital identities as they 
traverse through the organization. These identities, or roles, may change depending on 
the task, but the uniqueness maps back to the original identifier of the user. 

Managing user identities and identifiers across an enterprise has become crucial to 
network security as leaner staffs are now required to take on several roles to meet the 
organizational mission. The proliferation of identities has also increased the need to 
manage access to organizational assets. Success in managing organizational assets 
depends on the integrity, confidentiality, and privacy of its information and processes 
with the ability to audit governance, compliance, and use [Ref. 37]. Organizational 
systems today have become easily accessible creating the need to implement fine¬ 
grained, policy-based protection to protect their mission-critical data and services. 
Additionally, identities need to be managed to facilitate the right access to the right 
resources or users. Without properly managing these identities, a user may be given 
access to applications or resources that were not deemed necessary for the performance 
of his or her job. Organizations must ensure they control and audit the process of issuing 
a user credential, or allowing access to files, databases or Internet services. Effective 
identity and access management should consider a single view of all activities, such as 
user management and policy management, or creating a new user account. This will 
eliminate the need for the use of multiple consoles or applications when adding, 
modifying, or deleting users or specific information about the user, the user’s role, or 
identity. 

2. Identity and Access Management Tools 

Many IAM tools combine several functional components to create a best-of-breed 
solution. This solution provides maximum business value by integrating these 
components, yet making them interoperable with components from other vendors or with 
custom-developed applications [Ref. 36], Organizations are then enabled to choose a 
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fully integrated solution from a single vendor (called a suite), to combine selected 
components from different vendors that will work together (the real benefit of best-of- 
breed), or to phase in the pieces of a complete IAM solution using an evolutionary 
approach. Many IAM solutions include provisioning, policy enforcement (security), and 
end-to-end auditing to assist in ensuring that all aspects of the identity life cycle are 
securely and efficiently managed [Ref. 36]. 

Provisioning is defined as “the automation of business-oriented work flow of 
systems, resources, services and devices to employees, partners, contractors, suppliers 
and temporary workers.” [Ref. 38] User provisioning is the process for managing user 
identity enterprise-wide and beyond. User provisioning encompasses the identification 
of: 

• The types of users an organization will manage 

• The systems, application, and other business resources those users will 
need to access 

• The levels of access to those resources users will need 

• How the organization will create, update, and delete user accounts 

• How the business will guarantee secure access to its resources 

Provisioning of user objects, monitoring of all activities, reporting of all 

transactions, and de-provisioning (or un-assigning) of user objects are fundamental 
concepts of user life cycle management [Ref. 38], Organizations need to manage digital 
identities across the entire enterprise, and securing access to files, directories and 
databases while monitoring all of these activities with an end-to-end audit. Where 
provisioning differentiates from standard manual practices is that when user access is no 
longer required, access rights to all systems, devices, files and so on are terminated. 

Provisioning would be very ineffectual without the implementation of security 
management. The fundamental business process for which work flow is dynamically 
generated must support the organization’s security policies and business practices for 
which the provisioning of users is being conducted [Ref. 38]. With the use of this 
technology, the user information can be used to create a profile of a person or role that 
indicates exactly what resources should be allocated to the person or role. Any changes 
made to the profile can automatically trigger provisioning or de-provisioning activity 
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with little interaction required from the manager [Ref. 38], When a user moves to 
another command unit, all of the necessary work flow items would start and proceed to 
the reassignment of provisioned items, based on approvals received and any external 
systems, for instance the Human Resources department or military Manpower division. 

Most organizations desire to maintain a history of the types of events that have 
occurred when managing a user account. Performing auditing functions using the 
provisioning system helps ensure that all events and activities associated with identities 
or resources are tracked. Auditors can see “when an identity was created, who created it, 
where the identity went, what it accessed, what it touched, into what it morphed, when it 
was suspended and by whom, and when it was terminated” [Ref. 38]. Auditing services 
tracks all provisioning activity across the entire enterprise and extended enterprise. 

While an analysis of a multitude of vendors that advertised their IAM solution 
was conducted, only a couple truly demonstrated a solution that was integrated and 
contained the IAM capabilities mentioned above. These two companies, Computer 
Associates and IBM, are currently considered industry leaders in IAM technology. Of 
the two, Computer Associates offered the most comprehensive solution, which included 
not only the tools mentioned above, but also a wealth of additional easy-to-integrate 
components that could further enhance the network management experience. 

D. CONCLUSION 

This chapter provided a detailed analysis of industry accepted and best practices 
associated with IT outsourcing contracts. It outlined Gartner’s phased-approach to 
outsourcing, called the Strategic Sourcing process, and explained the importance of 
benchmarking and performance management in fostering successful partnerships in 
Phases 3 and 4 of the process. 

In particular, it expressed the importance of creating and monitoring SLAs using 
the following guidelines. Align outsourcing service levels to the business requirements; 
use the minimum number of service levels required to ensure satisfaction of the business 
requirements; ensure that financial, penalties, and incentives are included and that they 
align with the business requirements of the deal; and use a consistent approach when 
measuring perfonnance via service levels. While it is clear that establishing the 
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performance measures for an outsourcing contract is a daunting task, it is perhaps the 
most critical challenge to outsourcing success perfonned in Phases 3 and 4 of the 
Strategic Sourcing process. The two successful outsourcing endeavors included in this 
chapter confirms that careful SLA development, incorporating benchmarking into the 
contract and a host of other factors are imperative to ensure the success of the 
partnership. 

While there are several point products (or multi-vendor solutions) that could be 
used to tackle the NMCI account management challenge, it is recommended that an 
integrated IAM solution be considered to assist with account and access provisioning and 
management. 
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VI. CONCLUSION AND RECOMMENDATION 


A. INTRODUCTION 

This chapter provides a summary of the previous chapters by furnishing answers 
to the primary and secondary research questions presented in Chapter I. Additionally 
contained within this chapter are conclusions developed from the analysis of the Navy 
Marine Corps Intranet (NMCI) account management process and the associated 
challenges. The resulting research and analysis enabled the author to make clear and 
concise recommendations on specific areas of improvement to minimize additional costs, 
improve effectiveness, and maximize value within the enterprise. 

B. RESEARCH QUESTIONS 

As outlined in Chapter I and subsequently addressed in the preceding chapters, 
the answers to the research questions are represented in the following paragraphs. This 
section will include answers to the secondary research questions while the primary 
research question will provide a high-level answer in this section with a more detailed 
solution in the sub-section titled “Recommendation”. 

1. Primary Research Question 

a. How Might the U.S. Navy Reserve Component (USN RC) 
Effectively Manage Accounts in the NMCI Environment? 

There are several areas outlined in the research that demonstrate process 
inefficiency and therefore are candidates for change. Some of these include the definition 
of “the enterprise;” the coupling of accounts to seats; the current management process 
which causes the creation of Contract Line Item 0024s (CLIN 0024s) for additional 
accounts and the generation of CLIN 0026s for Move Add Change (MAC) requirements; 
and the use of multiple stove-piped Information Technology (IT) solutions. In order to 
mange not only accounts but the entire NMCI environment effectively, major changes 
should be considered in the tenns of the contract and the corporate business rules. A 
detailed analysis of the changes and the recommendations for improvement are included 
in the sub-section titled “Recommendation.” 
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2. Secondary Research Questions 

a. How Were the Accounts Allocated during NMCI Deployment? 

In the beginning stages of NMCI deployment, many commands allocated 
accounts by creating local processes of assigning accounts to seats. Earlier business rules 
required that each seat have at least one account assigned, therefore technical 
representatives were required to list all seats manually and subsequently manually cross- 
reference personnel accounts back to each seat. Ensuring that each seat had at least one 
account was a cumbersome process that was labor-intensive and in some cases required 
multiple personnel to perform. With little guidance and no standardized IT solution, 
most were required to create manual processes and use whatever IT resources they had 
locally available. 

As the NMCI deployment began to increase rapidly and commands began 
to cutover at record pace, the Department of the Navy (DoN) slowly began to realize how 
inefficient the process was and requested the creation of an IT solution to help ease the 
management nightmare. Over time, several IT solutions were created to handle different 
functions within the overall process (see Chapter III for more detail). While these 
systems lighten some of the burden, they created additional layers for the technical 
representatives and further complicated the overall management process. These 
additional layers or stove-piped systems required technical representatives to enter data in 
the NMCI Enterprise Tool (NET) at deployment. Once a command was cutover, account 
requests and all other service requests were performed using the Service Request 
Electronic Form (SR eForm). Billing and auditing functions resided in Electronic Market 
(eMarketplace). 

These are considered the corporate or enterprise-level systems, however 
none of them can be considered an accurate central data repository. With all these 
solutions, technical representatives are still required to maintain a locally generated 
central data repository to consolidate and effectively track resources for which they have 
overall management responsibility. 
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b. How Are the USN RC Customer Technical Representatives 
(CTRs) Currently Tracking NMCI Accounts per Region? 

Chapter IV provides a detail analysis of the As-Is process for the NMCI 
account management process. The principles of Business Process Redesign (BPR) as 
defined by Omar El Sawy and the Knowledge-Value Added (KVA) methodology created 
by Housel and Bell were used to capture and illustrate the As-Is process and to 
quantitatively determine the amount of value that each sub-process provides to managing 
accounts. Surveys, site visits, and interviews were the primary means of data collection 
in an effort to capture the current process. However, the data collection revealed there is 
no standardized method for tracking accounts either across the enterprise or within the 
regions. 

While there was no standardized process, four scenarios and numerous 
sub-processes showed some commonality across the regions and these sub-processes 
were used to devise the As-Is model. As previously mentioned, the technical 
representatives were required to use many manual processes such as manual logbooks 
when in-processing and out-processing Users and phone calls to Users to verity possible 
name matches in the Global Address List (GAL). Additionally, all requests that required 
contractor action had to be submitted to the next higher technical representative in the 
organizational chain of command. At the beginning of this research, these requests were 
sent via email, but recently the sub-process was modified to allow entry into the web- 
based SR eLonn. 

Asset management and some account management were performed in 
NET while asset and account invoice auditing were perfonned using eMarketplace. 
Other systems like Active Directory and the GAL were used to verify account status. 
While automation has been incorporated into the process, none of the systems have been 
integrated to allow data to be exchanged seamlessly or synchronized to enable the data 
integrity amongst all the platfonns. This has required the technical representatives to 
input common data and pull inaccurate data from each system. Currently, the use of 
multiple stove-piped IT systems (both locally and web-based) have become the IT 
solution of choice, yet the process continues to be labor-intensive and ineffective. 
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c. How is the Navy Reserve Forces Command Currently Managing 
NMCI Accounts for the USN RC? 

Chapter IV also provides a detail analysis for this question. When acting 
in the capacity of an assistant or deputy technical representative (ACTR/DCTR), the 
Navy Reserve Forces Command has been required to manage accounts using similar 
processes and the same IT tools identified under the previous question. They have used 
the same solutions but have had access to a higher-level management view within the 
web-based systems. Since they have had overall responsibility for all of the USN RC, 
they have been required to review orders before final submission, make approvals and 
disapprovals, and forwarded major requests to the contractor. Again, these functions 
have been accomplished using the same stove-piped web-based IT solutions previously 
mentioned and by using email and phone. 

d. How is the U.S. Navy Active Component (USN AC) Currently 
Managing NMCI Accounts? 

Phone conferences with USN AC representatives in the office of the 
Director of NMCI confirmed that the USN AC has been managing accounts using the 
same IT systems and tools used by the USN RC. The process of performing these tasks 
may differ as there has been no standardized process or policy by either higher echelon 
command. While capturing the process for the USN AC is out of the scope of this thesis, 
a similar approach using the BPR principles and KVA methodologies is recommended to 
understand exactly how the process is performed. 

e. How are Some of the Large Commercial Companies, which Have 
Adopted the Seat Management Concept, Successfully Managing 
Accounts across an Enterprise Solution? 

Chapter V identifies a phased approach to strategic outsourcing and seat 
management. The approach discussed in this research, called the Strategic Sourcing 
Process, has become widely accepted by corporate America and has gained recognition 
as an industry best practice for IT outsourcing. The process outlines four key phases 
(Sourcing Strategy, Evaluation and Section, Contract Development, and Sourcing 
Management) and identifies key functions that must be considered in each of these 
phases. One key aspect of the phased-approach is the establishment and evolution of a 
true “partnership” between the service provider (SP) and service recipient (SR). 
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Incorporating active and continuous benchmarking as well as the 
establishment of clear and concise Service-Level Agreements (SLAs) have proven the 
key to outsourcing and seat management success. Using benchmarking to determine how 
well the partnership is working enables the SR to gauge the SP’s perfonnance by 
comparing it to other organizations that are of equal size, complexity, and outsourcing 
functions. Many corporate companies also equate their success in outsourcing to the 
development of SLAs. Using SLAs as a contractual measure and monitor of performance 
to ensure that the contractor meets or exceeds the expectations of the organization is also 
critical for meeting the mission of the organization. Chapter V provides more 
information about benchmarking and SLAs and therefore will not be repeated in this 
section. 

/. What are the ‘Best-Of-Breed’ COTS Products Used by Industry 
for Account Management? 

Although a true enterprise solution that could handle all the functionality 
required for NMCI management could not be found, the Identity and Access 
Management (IAM) solution could be used to tackle most of the identified problems 
associated with managing accounts. An IAM solution is capable of managing user 
accounts, identities, roles, and directory access across multiple platforms to create a best- 
of-breed solution. By using provisioning technology to manage user objects, administer 
digital identities, and to monitor the user’s activities and history, the CLIN 0024s created 
because of duplicate accounts and multiple accounts could be dramatically reduced. 

C. RECOMMENDATIONS 

This section includes a more detailed response to the primary thesis question 
“How might the U.S. Navy Reserve Component (USN RC) effectively manage accounts 
in the NMCI environment?” and the secondary question “What would be a feasible non¬ 
technical solution that the USN RC, and perhaps the USN AC, could implement?” 

1. The Proposed ‘Radical’ Solution 

To develop the proposed solution, the principles of BPR discussed in Chapter IV 
and defined by El Sawy were used. Additionally, Housel and Bell’s KVA methodology 
was used to calculate the Return on Knowledge (ROK) for each new or modified sub¬ 
process. The specified business rules for the NMCI account management process limit 

the adoption of many aspects of the To-Be proposed solution in Chapter IV. Therefore, a 
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‘radical’ solution has been designed that will dramatically change the manner in which 
account management is currently performed. Levels of efficiency and costs savings will 
exponentially increase with the implementation of this proposal. 

The ‘radical’ zero-based review process assumes that the current business rules do 
not exist and that contracts can be modified based on the following recommendations for 
drastically changing the account management process: 

• Redefine the ‘enterprise’ to consolidate the USN AC and the USN RC 
budgets and NMCI funding and management oversight. If accounts 
are to remain coupled with seats, the enterprise should be redefined and 
accounts should be pooled just as initially intended (see Chapter 111). This 
will allow the USN RC complete access to any unused accounts derived 
from seats of the USN AC. 

• Overall NMCI management responsibility will reside at the USN 
Echelon II level, truly demonstrating the “One-Navy” envisioned by 
senior leadership. 

• Establish a standard policy for implementation across the claimancy. 

The survey results showed that the technical representatives not only need 
guidance, but have requested that policies and procedures be established. 

• Train the users on how to use the current IT tools and any tools that 
may be mandated in the future. Again, the surveys and the site visit 
revealed that users are not aware of the functionality and procedures of 
important management tools such as NET, SR eForm, and Active 
Directory structure. These applications and databases are critical to 
successful account management and if not used properly, will reduce 
efficiency and USN RC will continue to incur unnecessary CLIN 0024 
and CLIN 0026 costs. 

• Renegotiate NMCI contract to decouple seats from accounts. Taking 
into consideration the cost of hardware vs. the cost of an account, contract 
renegotiation could reduce overall spending on NMCI accounts while 
simplifying the management process. Attaching personnel (i.e., accounts) 
to hardware (i.e., seats) in such a dynamic organization as the DoN will 
continue to be a management nightmare as people are constantly 
relocating. For example, consider increasing the cost of a seat by what it 
currently costs to manage the two ‘free’ accounts. The cost of the 
accounts would then be decreased to compensate for the increase in seat 
cost. The cost and the method of calculation should be agreed upon by the 
government and the contractor. Attaching personnel (i.e., accounts) to 
hardware (i.e., seats) in such a dynamic organization as the DoN could 
continue to be a management nightmare as people are constantly 
relocating. 
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• Create an integrated web-based solution, which is thoroughly beta- 
tested with investments made in the upfront requirement analysis to 
ensure the solution meets the user’s needs. The solution should 
contain the functional and quality attributes required for overall 
NMCI management. This tool should combine all functions of NET, SR 
eFonn, eMarketplace, and any contractor-specific systems. One tool 
promotes data integrity and ease of management. 

• To assist in defining the requirements for such a tool, the author has 
created a detailed Functional Requirements document that includes not 
only the required functionality for the government, but also the minimum 
requirement for the contractor’s interface. See Appendix D. Additionally, 
Appendix E contains a Detail Design document to illustrate a functionality 
that was included in the web-based prototype of the requirements. Each 
web-page or view in Appendix E is traceable back to each requirement 
from Appendix D. 

• Once an integrated system has been created, provide an automatic 
interface between it and existing legacy databases in Navy Standard 
Integrated Personnel Systems (NSIPS) or Defense Enrollment 
Eligibility Reporting System (DEERS) and the civilian personnel 
management system equivalent. Make use of a unique identifier such as 
Social Security Number w/Common Access Card (CAC) to update the 
management system, Active Directory, and NMCI (in lieu of the current 
MAC process) automatically as the User transfers from command to 
command throughout his or her career. 

• Strong consideration should be made in the implementation of the 
COTS enterprise IAM solutions mentioned in the previous chapter. 

These solutions directly address many of the account management issues 
previously mentioned and could provide an immediate gain in efficiency 
while decreasing the $35 million paid for additional accounts. IBM and 
Computer Associates are industry leaders in the IAM solution and 
therefore should be contacted on the feasibility of implementation. 

Implementation of these recommendations would eliminate most account 
management responsibilities currently performed by technical representatives. The 
technical representatives would only be responsible for the maintenance and tracking of 
hardware. 

Figure 28 depicts what the process flow would entail if these recommendations 
were accepted and implemented. As demonstrated, this would significantly simplify 
NMCI account management and would require little intervention by the users. Again, 
this recommendation assumes a level of system interface that does not currently exist. 


95 



Radical Process Recommendation 


r 


*\ 


User reports to 
inprocesa Into Ihe 
Navy<MEPSf 
CIVPERS/ 
NROTC, etc.) 








NSIPSfCIVPERS 
record created. 
System generates 
reguest for new account 


Profile creation 
requesl recorded 
in NET 


User 

Outprocesses 

Command 


User Inprocesses 
Gaining Command 


NSIPS-'CfVPERS 
System generates 
" request to move in 
NET 


User 

Outprocesses 

Navy 



NSIPS'CIVPERS 
System generates 
request to delete 
in NET 



NET generales a 
work dcket to 
delete aecoi/it 



SRMAC Team 
deactivates 
account in Active 












Recommendation: 

Completely de couple seals from accounts be re-negotiating contract with EOS. As a 
oart of the re-negotiation, the seat cost would be reduced by an agreed upon amoi/tt 
33sed on the percentage of ihe seat cost currently devoted to managing the two free' 

mound. 

Every account would be biled separately based on half of the seat-cost reduction or a 
leqotiated cost to manage one account Thus, the requirement for CLIN 0024s go away. 



Changed Process 


.. 




Figure 28. Radical Process Flowchart. 


Figure 29 illustrates the ‘radical’ KVA analysis based on the proposed process 
flow in Figure 28. The spreadsheet shows a relative comparison in the ROK between the 
As-Is and To-Be ‘radical’ processes. As demonstrated by the grayed rows, most human 
intervention is removed, which increases the knowledge in the interface between the IT 
systems and decreases the errors caused in the submission of requests. The relative 
comparison between the two processes yields an increase in ROK and efficiency of 63% 
(40.47% /24.75%=63%). 
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Figure 29. Radical KVA Spreadsheet. 


D. CONCLUSION 

The NMCI account management process has made tremendous progress since the 
inception of the NMCI network. Flowever, in order for the system to evolve fully, the 
business rules should include continuous process improvement with the actors (i.e., A/D 
CTRs) in mind. The users are an important part of the process and they could provide 
useful recommendations for changes in the process if given the opportunity. Creating a 
forum or Community of Interest (COI) for them would enable them to express their 
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concerns and provide beneficial solutions. This COI would be in addition to the 
Enterprise Account Management Working Group (EAMWG) and/or the EAMWG should 
include some of the lower-level users in its configuration. The working group must meet 
often and on a continual basis while providing feedback to senior leadership. This 
ensures that addressing the NMCI account management issues become and remain a 
priority with flag-level support. 

Developing an integrated enterprise-level tool should be of the highest priority. 
The research revealed that current stove-piped systems such at NET, SR eForm, and 
eMarketplace are inefficient and ineffective in their current state. While many reasons 
for their inefficiency and ineffectiveness could be mentioned in this section, it is more 
important to note the research showed these systems were neither well developed nor 
well deployed, therefore contributing largely to the $35 million per year for the last 
several years for additional, and perhaps unnecessary, accounts. The inability to 
effectively manage accounts has caused friction between the Service Provider (SP) and 
the Service Recipient (SR). This strain in the partnership, as well as the findings in this 
research, has led the SR (the EISN RC) to search for creative ways to minimize the 
additional costs associated with managing accounts as they have started an initiative 
which will cancel several thousand accounts believed to be in excess. This initiative 
should force the SP to develop or purchase an automated solution that is capable of 
performing accurate audits on the allocated accounts. As mentioned in the previous 
section, a strong recommendation is also made to review and detennine a viable 
enterprise IAM COTS solution that can be used by the USN AC and USN RC. While 
this solution does not address all functionality associated with NMCI management, it 
does specifically address the issues concerned with account management. It is believed 
that the functionality built into these solutions could reap immediate benefits and 
substantially decrease the $35 million bleeding that the USN RC is currently 
experiencing. 

Further, the research surveys revealed that many users are not aware of the 

resources available to assist with account management. One in particular is the use of 

Active Directory, and not the GAL, to verify existing accounts and compare them with 

NET and eMarketplace. The majority are unaware how to map their local computer to 
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Active Directory in order to view exactly which accounts are being billed by the 
contractor. Instead, the GAL’s email account information is used, which is downloaded 
to a local resource (i.e., spreadsheet or database) to complete their monthly validation and 
reconciliation. 

This seems to indicate that the users want to manage properly, but do not kn ow 
how to manage because they have not been properly trained. This could easily be 
resolved if a web-based training curriculum were established to assist them in learning 
how to use the currently available tools. Education and training in this area is critical, 
and if not done, the account management process will continue to be ‘a challenge’ despite 
other future initiatives (i.e., the incorporation of additional modules for NET or other 
changes in the IT systems). 

Lastly, the other recommendations made in the ‘radical’ process should be 
considered and researched. Parts of the solution already exist in the existing legacy 
systems, but what remains requires some modification to the overarching policy and 
systems to support integration. By analyzing and mapping the current processes and 
using a methodology such as KVA to measure the knowledge in each of the sub¬ 
processes, managers can identify those areas not providing much value to the overall 
process and recommend more effective solutions. 
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APPENDIX A. CONTRACT LINE ITEM (CLIN) LIST 


CLIN 

Description 

Last Posted 

0001AA 

Fixed Work Station, Red 

13-Nov-03 

0001AB 

Fixed Work Station, White 

13-Nov-03 

0001AC 

Fixed Work Station, Blue 

13-Nov-03 

0001 AD 

Fixed Work Station, Thin Client 

4-Aug-03 

0001AE 

Remote User Credit (Moved to CLIN 004105) 

19-Feb-03 

0001AF 

Fixed Workstation, Classified Thin Client 

15-Dec-03 

0002AA 

Portable Seat 

13-Nov-03 

0002AB 

Ultra-Lightweight Portable Seat 

13-Nov-03 

0003AA 

Embarkable Work Station, Full Service 

13-Nov-02 

0003AB 

Embarkable Work Station, Limited Service 

28-Apr-04 

0004AA 

Embarkable Portable Seat, Full Service 

15-Dec-03 

0004AB 

Embarkable Portable Seat, Limited Service 

26-Mar-02 

0004AC 

Non-Ruggedized Deployable Portable 

13-Nov-03 

0005AA 

Basic Hybrid Seat 

30-Mar-04 

0005AB 

Enhanced Hybrid Seat 

30-Mar-04 

0005AC 

Reserved 

16-Jan-02 

0005AD 

Personal Access Package - 100% Concurrent Use 

30-Mar-04 

0005AE 

Personal Access Package - 30% Concurrent Use 

30-Mar-04 

0006 

Additional Standard Wall Plug Service 

21-May-03 

0006AA 

Additional Standard Wall Plug Seivice 

21-May-03 

0006AB 

Unclassified Wall Plug - Service Only 

21-May-03 

0006AC 

Classified Wall Plug - Service Only 

21-May-03 
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CLIN 

Description 

Last Posted 

0006AD 

Unclassified Wall Plug 

30-Mar-04 

0006AE 

Classified Wall Plug - Inside a Controlled Access Area 

30-Mar-04 

0006AF 

Classified Wall Plug - Outside a Controlled Access Area 

30-Mar-04 

0006AG 

Project Wall Plug 

30-Mar-04 

0006AH 

Switch Port - Low Bandwidth Service 

22-Sep-03 

0006AJ 

Switch Port - High Bandwidth Service 

22-Sep-03 

0006AK 

Sub-Device IP Address Management Service 

22-Sep-03 

0006AL 

Project Wall Plug Service (Group of 8) 

13-Feb-04 

0006AM 

Project Wall Plug Service (Group of 12) 

13-Feb-04 

0006AN 

Project Wall Plug Service (Group of 12) 

13-Feb-04 

0006AP 

Project Wall Plug Service (Group of 12) 

13-Feb-04 

0007 

High-End Upgrade Packages 

N/A 

0007 

For CLIN 0001AA Fixed Workstation Red 

13-Nov-03 

0007 

For CLIN 0002AA & 0002AB Portable 

13-Nov-03 

0007 

For CLIN 0003AA Full Service Embarkable 

13-Nov-02 

0007 

For CLIN 0004AA Full Service Embarkable Portable 

12-Dec-01 

0008AA 

Mission-Critical Upgrade Package - Single Connection 

22-Dec-04 

0008AB 

Mission-Critical Upgrade Package - Dual Connection 

22-Dec-04 

0009AA 

Classified Connectivity Upgrade Package 

22-Apr-03 

0009AB 

Switchable Classified Connectivity (Thin Client Solution) 

22-Oct-03 

0009AC 

Switchable Classified Connectivity (Dual CPU Solution) 

26-Mar-02 

0009AD 

Re-Bootable Classified Connectivity Upgrade Package 

6-Mar-02 

0009AE 

Switchable Classified Connectivity Upgrade Package (Dual CPU Solution/White) 

26-Mar-02 

0009AF 

Switchable Classified Connectivity Upgrade Package (Dual CPU Solution/Blue) 

26-Mar-02 
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CLIN 

Description 

Last Posted 

0009AG 

Switchable Classified Connectivity Upgrade Package (Dual CPU 
Solution/Portable) 

26-Mar-02 

0009AH 

Switchable Classified Connectivity Upgrade Package (Dual CPU Solution / Non- 
Ruggedized Deployable Portable) 

24-M-02 

0010AA 

Basic Voice Seat 

4-Dec-00 

0010AB 

Business Voice Upgrade Package 

4-Dec-00 

0010 AC 

Mission-Critical Voice Seat Upgrade Package 

9-Apr-01 

0010 AD 

Pier Voice Line 

4-Dec-00 

0010AE 

Pier Voice Trunk 

4-Dec-00 

001 OAF 

Commercial Voice Seat 

4-Dec-00 

0010 AG 

Commercial Voice Connectivity 

4-Dec-00 

0011 

Secure Voice Seat 

4-Dec-00 

0012 

Mobile Phone Seat 

4-Dec-00 

0013 

Personal Paging Service Seat 

24-Jul-02 

0014 

Fixed Video Teleconference Seat 

4-Nov-03 

0015 

Moveable Video Teleconference Seat 

4-Dec-00 

0015AA 

Basic Moveable VTC Seat 

22-May-02 

0015AB 

Pligh-End Moveable VTC Seat 

22-May-02 

0015 AC 

Mission-Critical Moveable VTC Seat 

4-Dec-00 

0015 AD 

Premium Moveable VTC Seat 

22-May-02 

0016AA 

Additional File Share Services - Unclassified (10Gb) 

30-Mar-04 

0016AB 

Additional File Share Services - Classified (10Gb) 

30-Mar-04 

0016AC 

Email Storage - Unclassified (25Mb) 

30-Mar-04 

0016 AD 

Additional Email Storage - Classified (25MB) 

30-Mar-04 

0017 

Internet Access for Mobile Phone Seat 

4-Dec-00 
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CLIN 

Description 

Last Posted 

0018 

Classified Remote Access Service 

26-Mar-02 

0019 

Reserved 

2-Jul-00 

0020 

Data Seat Voice Communications Upgrade 

9-Apr-01 

0021 

Defense Messaging System Data Seat Upgrade 

6-Mar-02 

0022AA 

Basic Desktop VTC 

1-Aug-03 

0022AB 

High-End Desktop VTC 

1-Aug-03 

0023 

Optional User Capabilities 

25-Apr-05 

0024 

Additional Non-Classified Account 

9-Apr-01 

0025 

Additional Classified Account 

9-Apr-01 

0026 

Additional Moves, Adds, Changes 

21-May-03 

0026AA 

Additional Moves, Adds, Changes 

26-Jun-03 

0026AB 

Physical MAC Group of 50 

26-Jun-03 

0026AC 

Physical MAC - Group of 250 

26-Jun-03 

0026AD 

COI MAC 

26-Jun-03 

0026AE 

Voice Moves, Adds, and Changes 

22-Sep-03 

0026AF 

VTC Moves, Adds, and Changes 

5-Jan-01 

0026AG 

Annual Administrative MAC 

21-May-03 

0026AH 

Annual Physical MAC 

21-May-03 

0026AJ 

Annual Physical MAC (Needing a Wall Plug) 

21-May-03 

0026AK 

Annual Embarkable MAC 

21-May-03 

0026AL 

Administrative MAC (Single) 

26-Jun-03 

0026AM 

Physical MAC (Single) 

26-Jun-03 

0026AN 

Embarkable MAC (Single) 

26-Jun-03 

0026AP 

Project MAC (Single) 

4-Nov-03 
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CLIN 

Description 

Last Posted 

0026AQ 

Project MAC Service 

11-Mar-04 

002 7AA 

Standard Low Bandwidth Application 

21-May-03 

002 7AB 

Standard Medium Bandwidth Application 

21-May-03 

0027AC 

Standard High Bandwidth Application 

21-May-03 

002 7AD 

Mission-Critical Low Bandwidth Application 

4-Dec-00 

0027AE 

Mission-Critical Medium Bandwidth Application 

6-Feb-01 

0027AF 

Mission-Critical High Bandwidth Application 

4-Dec-00 

002 7AG 

Legacy Application Server Connection 

26-Jun-03 

0028 

Data Warehousing 

4-Nov-03 

0029 

Legacy Systems Support 

4-Nov-03 

0030 

Network Operations Display 

16-Jan-02 

0031 

Military Personnel Core Competency Development (Sea-Shore Rotation and 
Operating Forces/Supporting Establishment Rotations) 

25-Jan-02 

0032 

External Network Interface 

4-Nov-03 

0033 

Information Technology/Knowledge Management Retraining Program 

6-Feb-01 

0034 

Satellite Terminal Support 

4-Nov-03 

0036 

OCONUS Service 

8-Apr-05 

003 8AA 

Developer Fixed Workstation Upgrade 

22-Dec-04 

003 8AB 

Developer Portable Workstation Upgrade 

26-Mar-02 

003 8AC 

S&T Terminal Services 

22-Sep-03 

003 8AD 

S&T Fast Ethernet Wall Plug 

16-Jan-02 

003 8AE 

S&T Wall Plug Service - Modified Gigabit Ethernet Network Transport-Lots of 4 

16-Jan-02 

003 8AF 

S&T Wall Plug Service - Modified Gigabit Ethernet Network Transport-Lots of 8 

16-Jan-02 

003 8AG 

S&T Wall Plug Service - Modified Gigabit Ethernet Network Transport-Lots of 16 

16-Jan-02 
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CLIN 

Description 

Last Posted 

003 8AH 

S&T Network Transport - Other 

4-Nov-03 

4101 

Desktop Support 

19-Feb-03 

4102 

Desktop Refresh 

19-Feb-03 

4103 

Desktop Refresh With NMCI Gold Disk Software 

19-Feb-03 

4104 

Assumption of Responsibility 

19-Feb-03 

4105 

Remote User Credit 

19-Feb-03 

4106 

Remote User Credit (Japan) 

6-Jun-03 

0043 

Asbestos Material Abatement 

1-Aug-03 

0044 

Department of Defense Mentor-Protege Program (0044AA - 0044AF) 

23-Dec-03 

0046 

File Removal Service 

19-Jan-05 

0047 

Software Certification (0047AA - 0047AD) 

24-Nov-04 

0048 

Software Distribution (0048AA - 0048AB) 

22-Dec-04 

0049 

Hardware Certification and Installation (0049AA - 0049AD) 

22-Dec-04 

0051 

Waterfront Support (0051AA - 0051AB) 

27-May-05 

0053 

Premier Support (0053AA - 0053AB) 

27-May-05 
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APPENDIX B. NMCI ACCOUNT MANAGEMENT SURVEY 

QUESTIONS 


Navy Marine Corps Intranet (NMCI) 

Account Management Survey Questions for all Navy Reserve Activities (NRA) 

For the purpose of this survey, Reservists include all Drilling Reseri’ists (DRILLRES), 
Full Time Support (FTS) personnel are explicitly separated from the Reservists category. 

Administrative 

1. Name of your Navy Reserve Activity (NRA): (data entry field, 30 char) (REQ) 

2. NRA UIC: (data entry field, 10 char) (REQ) 

3. Your Echelon IV command: (REQ) 

(Pull down menu): 

i. REDCOM Northeast 

ii. REDCOM Mid Atlantic 

iii. REDCOM Southeast 

iv. REDCOM South 

v. REDCOM Southwest 

vi. REDCOM Northwest 

vii. REDCOM Midwest 

viii. NAR Atlanta 

ix. NAR Brunswick 

x. NAR FT Worth 

xi. NAR Jacksonville 

xii. NAR New Orleans 

xiii. NAR Norfolk 

xiv. NAR Point Mugu 

xv. NAR San Diego 

xvi. NAR Whidbey Island 

xvii. NAR Willow Grove 
xviii. Other 

a. If other, what is the name of your echelon IV command? (Text Box) 
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4. Date NRA cutover to NMCI: (month, year drop down menu) (REQ) 

5. Number of Reservists assigned to your NRA: (Data Entry Field: 5 char) (REQ) 

6. Number of Full Time Support personnel assigned to your NRA: (Data Entry 
Field: 5 char) (REQ) 

7. Do the majority of the DRILLRES drill on or offsite? 

(2 radio blocks: “on-site” or “off-site”) (REQ) 

8. Is NMCI management a primary duty or collateral duty? (2 radio blocks: “primary 
duty” or “collateral duty”) (REQ) 

a. If a collateral duty, does it warrant a full-time position? (3 radio blocks: 
“yes” or “no” or “not a collateral duty”) (REQ) 

b. If a primary duty, does it occupy sufficient time to be warranted? (3 radio 
blocks: “yes” or “no” or “not a primary duty”) (REQ) 

9. Does your command have a standardized check-in and check-out procedure (i.e. 
check-in check-out sheet)? (2 radio blocks: “yes” or “no”) (REQ) 

a. If yes, is the NMCI account management process li nk ed with your 
DRILLRES/FTS check-in and check-out process? (2 radio blocks: “yes” 
or “no”) 

b. How is the check-in and check-out procedure enforced? (text box) 

NMCI Account Management 

10. Do you have a standardized procedure for NMCI account management? (2 radio 
blocks: “yes” or “no”) (REQ) 

11. If you answered “yes” to #10, please explain in detail your step-by-step NMCI 
account management process for the following situations: 

a. Checking in a DRILLRES new to the Navy Reserve: (Data entry field, 

250 char) 

b. DRILLRES/FTS transferring to your command from another command: 

(Data entry field, 250 char) 

c. A DRILLRES/FTS leaving your command and transferring to another 
command: (Data entry field, 250 char) 
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d. A DRILLRES/FTS terminating service in the Navy Reserve: (Data entry 
field, 250 char) 

e. DRILLRES transferring to active duty: (Data entry field, 250 char) 

12. What are the most difficult or time consuming parts of the process? (Data entry 
field, 250 char) (REQ) 

13. What automation tools are utilized by the NMCI account manager? (checkboxes: 

“Excel” and “Access” and “Word” and “NET” and “NSIPS” and “Other” + data 
entry field to explain “other”) (REQ) 

14. Prior to submitting a MAC, do you verify that an NMCI account does not already 
exist for that individual? (2 radio blocks: “yes” or “no”) (REQ) 

a. If yes, what is your verification process? (Data entry field, 250 char) 

15. What steps do you take if the individual already has an NMCI account? (Data 
entry field, 250 char) (REQ) 

16. How do you ensure that every DRILLRES/FTS has only one NMCI account? 

(Data entry field, 250 char) (REQ) 

17. Do you verify legitimate multiple account requirements? (2 radio blocks: “yes” 
or “no”) (REQ) 

a. If yes, please explain how you verify legitimate multiple account 
requirements (i.e. A contractor who also is a DRILLRES) (Data entry 

field, 250 char) 

18. Do you submit your MAC/order request to the next higher echelon (higher level 
Customer Technical Representative (CTR)) for approval prior to placing the order 
or MAC? (radio blocks: “yes” or “no”) (REQ) 

19. Do you receive notification when an account is created or modified? (radio 
buttons, “yes” or “no”) (REQ) 

NMCI Account Management Processing Time 

20. On average, how many times a week does each of these occur? 

a. Checking in a DRILLRES new to the Navy Reserve: (REQ) 

b. DRILLRES/FTS transferring to your command from another command: 

(REQ) 
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c. DRILLRES/FTS leaving your command and transferring to another 
command: (REQ) 

d. A DRILLRES/FTS terminating their service in the Navy Reserve: (REQ) 

e. A DRILLRES transferring to active duty: (REQ) 

(for each a, b, c, d, e, build nine radio blocks: “0-10” or “11-20” or “21-30” or 
“31 -40” or “41 -50” or “51 -60” or “61-70” or “71 -80” or “over 80 times”) 

21. On average, how long does each individual process take (from the time the 
request is made to the time the action is completed)? 

a. Checking in a DRILLRES new to the Navy Reserve: (REQ) 

b. DRILLRES/FTS transferring to your command from another command: 

(REQ) 

c. DRILLRES/FTS leaving your command and transferring to another 
command: (REQ) 

d. A DRILLRES/FTS terminating their service in the Navy Reserve: (REQ) 

e. A DRILLRES transferring to active duty: (REQ) 

(for each a, b, c, d, e, build nine radio blocks: “half day” or “one day” or “one 
and a half days” or “two days” or “three days” or “four days” or “five days” or 
“within a week” or “over a week”) 

22. Do you have a method for managing accounts derived from seat purchases (i.e. 
Two accounts for each unclassified seat, five accounts for each classified seat)? 

(radio blocks: “yes” or “no”) (REQ) 

a. If yes, please explain your management process: (data entry field, 250 
char) 

b. How do you track the CLINS (by quantity and type) you have purchased? 

(data entry field, 250 char) (REQ) 

23. On average, how many hours per week do you spend on account management? 
(radio buttons, “0-5 hours” or “6-10 hours” or “11-15 hours” or “16-20 hours” or 
“21-25 hours” or “26-30 hours” or “over 30 hours”) (REQ) 

24. On average, how many hours per month do you spend on account management? 
(radio buttons: 0-10 hours, 11-20 hours, 21-30 hours, so on) (REQ) 
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25. If you did not have any automation tools at your disposal (Excel, NMCI 
Enterprise Tool (NET), etc) and were forced to manage NMCI through logbooks, 
face-to-face communication, and other non-automated means, how much time do 
you predict it would take to properly manage NMCI accounts? (REQ) 

a. Predicted time per month (time in hours): (radio buttons “0-10, 11-20, 21- 
30, 31-40, 41-50, over 50 hours”) (REQ) 

Command Questions 

26. What outputs (in the form of reports, confirmations, emails, messages, etc) are 
part of your account management process? Please provide input to the following 
table, following the example provided, and list all applicable outputs. (REQ) 


Output Product 

Format Used 

Submitted To 

Frequency 

NMCI Update 

Access Report 

CO, XO, OPS 

Monthly 










27. Do you have access to the NMCI Enterprise Tool (NET)? (radio buttons, “yes” or 
“no”) (REQ) 

a. If yes, do you use NET to manage your NMCI orders and account data? 

(radio buttons, “yes” or “no”) 

b. If yes, what information are you entering into NET? (data entry field, 250 
char) 

28. How many hours do you estimate it would take to adequately train an individual 
(i.e. your relief) to perform account management? (radio buttons: “0-10 hours” or 
“11-20 hours” up to “over 80 hours”) (REQ) 

a. Of the training time allowance indicated above, how much of that time 
would be required to train an individual to handle the following tasks: 

i. Checking in a DRILLRES new to the Navy Reserve: (REQ) 

ii. DRILLRES/FTS transferring to your command from another 
command. (REQ) 
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iii. DRILLRES/FTS leaving your command and transferring to 
another command: (REQ) 

iv. A DRILLRES/FTS terminating their service in the Navy Reserve: 

(REQ) 

v. A DRILLRES transferring to active duty: (REQ) 

29. Do you have any recommendations, concerns or complaints about NMCI account 
management within your command? (data entry field, 250 char) 
a. Outside your command? (data entry field: 250 char) 
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APPENDIX C. INTEGRATED WEB-BASED ENTERPRISE TOOL 

PROTOTYPE 


The web-enabled database prototype/solution that was created would replace 
several of the applications that currently do not interface with any of the enterprise-level 
systems. The To-Be prototype was designed as an interim solution to ease the account 
management challenges for the claimancy until the next module of NET has been 
completed. It demonstrates the type of functionality that should be incorporated in a 
more robust version of the SR eForm or in the next module of NET. This prototype is 
not fully functional and should not be deployed in its current state as there are numerous 
technical functions, security considerations, and quality attributes that must be added 
before it is equipped to handle the magnitude of data required for an enterprise level 
solution. 

Several assumptions were made when designing the website, which are apparent 
in its demonstration, and appear as follows: 

• The prototype has no direct interface with NET 

• NET will continue to perform seat management as it does currently. This 
assumption was made because NET currently appears to perform seat 
management adequately and the issues surrounding seat management were 
not the focus of this project. 

• The data cleansing is complete or near completion. The prototype does 
not perform tasks associated with cleaning up the database from its current 
state 

• The prototype will be initially populated with data from Active Directory. 
After the data cleansing, all accounts will be loaded into this site before it 
becomes fully functional. 

The benefits of the functionality embedded in the prototype are tremendous. Each 
of the pages was designed with the user in mind and includes many of the quality 
attributes desired based on the user surveys. Additionally, the website was designed to 
achieve efficiency in management at all levels, from the lower level ACTR to the highest 
level CTR. Some of the advantages are: 
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• Addresses rapid MAC submissions with the use of auto-fdl and dropdown 
menus to populate repetitive data and enhance the user interface. This 
eliminates the need for the user to type common data manually for every 
MAC submission. 

• The site guides ACTRs/DCTRs through a standardized process for 
completing any request. It eliminates the ambiguity in completing a 
request, as the site will automatically present the next required step when 
the “submit” action button is selected. 

• Reduce duplicate accounts (in error). The site queries user names, lists 
match, and display the user’s account history. 

• The site has many embedded training links making it a user-friendly 
environment where account managers can easily learn the difficult NMCI 
tenninology, business rules, and Active Directory mapping. 

• The website will automatically submit requests to the contractor’s SRM 
Team to deliver and install hardware; to handle MAC requests; and 
generate trouble tickets. 

• Transparent linking of profiles to seats. Ensures 100% utilization of free 
accounts by attaching them automatically to seats. This is performed 
without any additional action required by the user. 

• The DCTR will be able to perfonn all the actions of an ACTR through 
access to their data repository. 

• The DCTR view shows a hierarchy of subordinate commands. 

• Security authentication and write access based on the login ID has been 
implemented. 

• Some fonn validation exists in the site but does not incorporate it into 
every required page. Some fields accept for information that is unique in 
the business rules (i.e., asset ID, seat ID etc.) 

• This prototype is also devoid of mandatory functionality to ensure 
integrity of the system and interface with enterprise-level systems (i.e., 
NET). 

The recommended/required outstanding items that should be added to the system 

are: 

• The site does not include bulk requests submissions although it is certainly 
recommended. 

• It does not interact with any other database and is only as good as the data 
that currently exist in the database. An interface should be built that 
would provide an interface to NET and perhaps Active Directory. 
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1. Summary 

Commander Naval Reserve Forces Command (CNRFC) desires an integrated enterprise-level 
web-based tool that will aid the assistant, deputy, and customer technical representatives (ACTR, 
DCTR, CTR) with managing the Navy Marine Corps Intranet (NMCI) seats 1 and accounts 2 . The 
current NMCI management process requires the use of a myriad of information technology (IT) 
applications and manual processes to perform daily tasks. The lack of connectivity between the 
systems, data integration, system training, and standardized business processes have made the NMCI 
management process tedious, inefficient and wasteful. Technical representatives are not able to 
effectively and efficiently track their seat and account totals as personnel are transferred to and from 
commands. This results in the creation of duplicate accounts, paying for accounts of personnel that 
have terminated their affiliation with the U.S. Naval Reserve (USNR), and providing funding for 
personnel that have transferred to a command that is outside of Reserve Force's (RESFOR) 
claim an cy. 

The NMCI contract was written to couple seats with accounts. The contract states that each 
unclassified seat is accompanied with two “free” accounts. Any accounts that exceed the total "free” 
accounts that accompany seats will incur a charge of approx $700 per annum. The nature of the 
contract has required close management of the total number of seats and accounts to ensure that 
maximum utilization of the “free” accounts is achieved. As previously mentioned, the use of the 
various heterogeneous IT systems, lack of training, and the lack of standardized processes has 
hindered RESFOR’s ability to effectively manage this process, and therefore has resulted in 
approximately $30 million per year in additional costs for accounts and a time-consuming labor- 
intensive process for the technical representatives. 


2. Project Goals, Justification, and Success Criteria 
2.1 Project Goals 


1 A seat is defined as any portable or desktop computing hardware purchased as part of an outsourcing seat 
management contract. 

2 An account is defined as a user’s login name to gain access to the NMCI network. Account information is 
entered into the network’s Active Directory to establish user authentication and profiles requirements. 


Developed by N61, IT Project Management Office 


122 






CMRFC Navy Marine Corps Intranet Enterprise Management Tool Functional Specifications 

Page 5 of 30 


Draft 

Currently the NMCI management process includes approximately five enterprise- 
level IT systems and a myriad of applications used for local tracking and management. The 
primary enterprise-level systems are: 

NMCI Enteiprise Tool (NET) with a primary function to manage seat data and 
for build-outs 3 of new commands. 

Electronic Marketplace (eMarketplace) for billing and invoicing. 

Service Request Electronic Form (SREform) for submission of hardware, 
software, and account Move-Add-Changes (MAC). 

MS Outlook Global Address List (GAL) to verify the existence of an account. 

MS Active Directory to verify account totals for billing purposes. 

Each of the various systems currently used maintains data that is critical for NMCI 
management. However, no capability exists to automatically exchange data between them 
for system updating purposes, and no synchronization exist between them for data integrity. 
The lack of a fully integrated system requires the technical representatives to retrieve data, in 
some cases redundant data, from each to perfoim daily routine tasks. 

Budget cuts have minimized funding dollars required to effectively train personnel on 
the current management systems, therefore, most training is performed through personnel 
turnover or through process performance. A standardized policy has not been established 
because the management process is consistently changing to meet the dynamics of the 
systems and business rales. 

The goal of this project is to create an integrated web-based NMCI management tool 
that will accurately track seats and accounts and that will ease the NMCI management 
process for the technical representatives. A web-based tool will enable the geographically 
dispersed technical representatives to gain access to critical data from any location in the 
world. Ultimately, the goal is to minimize costs associated with additional accounts and to 
decrease the labor required to perform daily tasks. 

2.2 Justification 

The enormous number of man-hours required for the technical representatives to 
perform the numerous tasks associated with the NMCI processes and management has caused 


3 A buildout is an action performed by the contractor before cutting over a command to NMCI. The buildout 
involves inputting administrative data that is specific to hardware assets (i.e. command, location, asset ID etc) 
and user accounts prior to delivery of the hardware and establishing the account in the NMCI Active Directory. 
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a decrease in service levels in other areas of responsibility. Many of the Echelon 4 V technical 
representatives perform the NMCI management responsibility as a collateral (or secondary) 
job assignment. The current process has become extremely labor-intensive and, in some 
instances, requires other command personnel to perform functional tasks that would have 
otherwise been performed by the technical representative as a primary job assignment. This 
shift in responsibility has placed an unnecessary burden on many commands that are already 
short-staffed. A solution is required to improve this process and provide the necessary 
feedback and reports for verification and accuracy of data submitted by the contractor. 

The current process, tools, and business rules have caused the USNR to accumulate 
an enormous amount of chargeable accounts, resulting in approximately $30 million in 
additional costs for user accounts. The elimination of excess accounts from the Active 
Directory has been a daunting task partially because technical representatives and users are 
having difficulty determining which accounts are excess and which are a justifiable need. 
Excess accounts can be categorized as duplicate accounts existing in the Active Directory that 
are not required. These accounts result in unnecessary and substantial charges to the USNR. 
The solution should assist in substantially minimizing the costs accrued for additional 
accounts by minimizing the excess accounts that currently reside in the system. 

Oftentimes, “free” accounts are occupied with accounts determined to be in an 
inactive status. An inactive account is defined as an account with no network activity since 
its creation or in the past 120 days. Accounts in this status also yield a chargeable account 
because they occupy a space on a seat that could otherwise be used for a valid account 
requirement. 

2.3 Success Criteria 

NMCIACTR Overall Unit Management Tool: Provide a status and total of all chargeable 
and non-chargeable seats and accounts. The tool shall also include a total of all MACs 
separated by seats and accounts. 


4 An Echelon is a Civil War term used to describe the arrangement of military troops during battle. In this 
document, it is defined as the hierarchy of military commands. The lower the echelon number, the higher the 
command in the reporting chain. For instance, an Echelon II command is one level above an Echelon HI in the 
reporting chain of command. 
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NMCI ACTR Seat and Asset Management Tool: This tool shall be available to all ACTRs 
to perform the following tasks: 


■ Place an order for a new seat (i.e. portable or desktop computer, peripheral that is not 

assigned to a computer) or new hardware (peripheral devices such as a printer, scanner or 
PDA, etc.). The tool shall allow entry of all the contractor required data fields and the 
request should automatically be submitted to the authorized submitter (DCTR) for 
approval prior to forwarding to the contractor for final action. 

■ View and edit seat data once a seat has been entered into the tool and installed. This 

allows the authorized initiator (ACTR) to quickly recall and administratively make 
modifications to information that may have been entered about a specific seat. Any 
administrative modification to seat or account data does not require the approval of the 
DCTR or action by the contractor, but is simply updating the current information that is 
within the database. 

■ View and Edit hardware and peripherals that have been entered into the tool and installed. 

This shall also allow the ACTR to administratively make modifications to information 
that may have been entered about a specific piece of hardware or peripheral 

■ Request an upgrade to an existing seat will allow the ACTR to submit a request for 

modification to a seat’s current configuration. This change may require additional costs 
therefore the tool should be sophisticated enough to forward any change/upgrade requests 
to the authorized submitter or DCTR prior to submission to the contractor. 

■ Request a seat to be relocated to another location. This shall enable an ACTR to use 

automation to recall all the seats and specify which seats will need to be moved and to 
provide their desired location. This is a billable action therefore the request for 
equipment relocation should be automatically submitted to the DCTR for approval prior 
to submission to the contractor. 

■ A view of all invoiced items with the seat identification number, any additional hardware 

that is attached to the seat, itemized costs for each, and the accumulated dollar total for 
monthly invoice validation. 

■ The ability to use automation to submit a request to return any seat to the contractor that is 

no longer required. The ACTR should have to perform minimal data entry for this action 
to occur by including a consolidated list of all seats, the ability to select the seat to return, 
pre-populated text entry fields that include the seat information, and an option to submit 
selected seat for return. 

■ The ability to administratively add any seat and the associated hardware peripherals that 
already exist at the command but is not already listed in the tool. This is an important 
feature for the organizations that have already cutover to NMCI and their initial order 
was not entered in the tool. The action shall be performed by the ACTR and no 
forwarding requirement to the DCTR or contractor exists. 

NMCI Account Management Tool: This tool shall be available to all ACTRs to perform 
the following tasks: 

■ The capability to in-process a new user or out-process and existing user. In-processing 

shall include the ability to automatically check the system to see if a user’s name exists in 
the system. If one exists, the system shall return all instances of that name, and the 
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account history, for verification of possible accounts that may have been previously 
assigned to the user that is in-processing. The account information of users that are out- 
processing shall be transferred from the losing ACTRto the gaining command’s ACTR’s 
inbox of the tool for acceptance. 

■ Newly-created accounts shall be automatically assigned by the system to a seat without 

any additional intervention required by the ACTR. Once the account totals have 
exceeded the total accounts that accompany the seats, the tool shall automatically assign 
these accounts to a chargeable MAC (called a CLIN 0024). 

■ The ability to view all accounts that are associated with the ACTR's command. This 

information shall mirror the information that exists in the NMCI Active Directory. 
Separation between the accounts that are billable and the non-billable accounts shall be 
made by listing each category separately and providing ght e totals for each. 

■ To automatically submit a request for a password to be reset. 

NMCI DCTR Seat and Asset Management Tool: This tool shall be available to all 
DCTRs to perform the following tasks: 


■ As the authorized submitter, the DCTR is required to approve any MAC requests before 

they are forwarded to the contractor’s Service Request Management (SRM) team. The 
DCTR’s web-based view shall include a webpage that contains an inbox of requests. The 
inbox shall include all requests forwarded from the lower-level ACTR’s from the Naval 
Reserve Activities (NRA) that are pending review and approval. 

■ The DCTR tool shall forward any requests that are approved to the contractor SRM team 

supervisor web tool for distribution between the contractor teams. 

■ The DCTR tool shall generate and submit requests in the absence of an ACTR. 

NMCI RESFOR Management Tool: This tool shall be available to all primary CTRs to 
perform the following tasks: 

■ Review all account and seat accumulated totals submitted by all technical representatives 

within the RESFOR claimancy. The tool shall include summary data for the total for 
each account status (billable, non-billable, used “free” accounts, unused “free” accounts, 
CLIN 0024’s required), total seats installed, and total seats pending installation. Total 
dollar amounts shall be automatically calculated for quick reference against the 
eMarketplace totals. CLIN 0024’s totals should be calculated in summary of all 
accumulated for quick reference. 

NMCI Contractor Management Tool: This tool shall be available to the supervisors of the 
SRM team to perform the following tasks: 

Supervisor: 

■ The Supervisor has overall management responsibility for all MACs submitted by the 

authorized submitter. Subsequently, the supervisor shall have sole authority to view 
accepted MACs and assign an SRM team that will be responsible for servicing the MAC 
requests. 
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■ Delineation between seat and account MACs is required for quick reference and MAC 

team assignment. The view should include a list of all pending MACs sorted by MAC 
number, MAC type, and date the MAC was submitted. 

■ Once a MAC is received, a supervisor shall be able to assign the MAC to a team by 

indicating the team number that will have responsibility to complete it. 

■ The supervisor shall be provided a separate view of all assigned or working MACs . 

Team: 


■ Each team has its own view that lists the MACs they have been assigned. 

■ A view of the MAC details enables the team to view the requests and to automatically 

provide a job completion status back to the Supervisor. 

Data Ownership: 

The system shall be constructed to promote data and system ownership by permitting ease in 
exporting data and system conversion in the event of expiration of the current outsourcing 
contract. 

3. Functional Requirement Features 

3.1 Requirement for Overall Management 
3.1.1 Usability 

Provide a user-friendly 5 web-based portal that enables easy access for all technical 
representatives (ACTRs and DCTRs) and SRM supervisor and team members to perform 
overall NMCI management. 

3.1.1.a 


Usability testing shall be conducted using a prototype of the site. Modifications to 
the system will be made based on the test results received from users of the system. Testing 
will include collecting data on the paths users take to do tasks, the errors they make, when 
and where they are confused or frustrated, how fast they perform a task, whether they succeed 
in doing the task, and how satisfied they are with the experience. 


5 For the purpose of this document, User-friendly can initially be defined as the measure of the quality of a 
user’s experience when interacting with the website. The site should have a consistent look and feel with a 
graphical user interface, the layout should be easy to navigate with maximum use of toolbars and hyperlinks. 
The colors should be simple and complimentary. To assist with the speed and efficiency, the site should allow 
minimum use of large graphical files that can slow the performance. 
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3.1.l.b 


The tool shall provide data integration across the information provided by the ACTR, 
DCTR. CTR, contractor Supervisor, and contractor Service Request Management (SRM) 
Teams. The data shall be reliable and consistent across all processes where feasible to allow 
for information sharing and analysis of data across all business functions. 

3.1.2 Embedded Training 

Include training information and definitions of key management terms. 

3.1.2.a 


Definitions of NMCI management terminology required to perform the tasks in the 
site shall be easily accessible via a hyperlink adjacent to where a term is used and where data 
referencing the terminology must be entered. 

3.1.2.b 


Visual aides and locations should be provided for items that need to be physically 
sited on hardware. These terms include but are not limited to: CLIN, option CLIN, sub¬ 
option CLIN, NMCI Seat ID and its location, NMCI Asset ID and its location. Service Tag 
Number, Computer Name, and Profile ID. A complete list of terms shall be defined by the 
contractor prior to the system design phase. 

3.1.3 ACTR Tool 

Provide a dynamic web-view summary of the billable, non-billable account, and seat 
totals for use by the ACTR. 

3.1.3.a 


This view shall also include a summary of the pending and returned MAC totals for 
accounts and seats. 

3.1.3.b 
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The view shall include an ACTR Toolbox that empowers the ACTR with the ability 
to perform account management and seat/asset management centrally. 

3.1.3.C 


Training aids that define a User Profile and illustrates how to map and view accounts 
in the Active Directory shall be included in the toolbox. 

3.1J.d 


The Account management section of the toolbox shall include the following account 
management functions: 

■ In-process users ; 6 

• Request password reset; 

■ Search MAC account history; and 

■ View Active Accounts. 

Conversely, the seat and asset management portion shall include the ability to: 

■ Order a new seat; 

■ Request an upgrade to an existing seat; 

■ Request a physical seat move; 

■ Turn in any excess seats; 

■ View/Edit seat data; 

• View/Edit hardware and peripherals; 

■ Validate eMarketplace Invoice; and 

■ Administratively add seats. 

3.1.3.1 In-process Users 

ACTRs are required to enter new users into the tool before a network account can be 
established. Each user should only have one account in the Active Directory. Establishing 
multiple accounts requires a justifiable reason and prior approval from the DCTR before 
another account can be created. Account status should be verified by querying the network’s 
Active Directory. 

3.1J.l.a 


6 In-processing auser entails administratively assigning aperson to ajob that is transferring to the command or 
someone that is new to the Naval Reserve. 
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Provide aweb-view that requires the technical representative to enter the user's first 
name, last name, and middle initial just as it appears on the military or government photo 
identification or common access card (CAC). User-friendly account search criteria should 
include a pre-populated selection list that allows the ACTR to search the database in the 
following account status categories: All, watchstander, active, temp account (training and 
visitor), locked, stale, disabled, and deactivated. The system should either return a list of all 
thenamesthat match the name of the user that was entered based to the search criteria or will 
allow the ACTR to add the user to a new page if there are no matches in the Active Directory. 
An ACTR will only be prompted to enter in anew user if a name match does not exist within 
the data repository. 

3.1.3.1.b 

The page shall include the following information about the user that will be added: 
Last Name, First Name, Middle Initial, NMCI network user name, UIC, account 
classification (classified or unclassified), site code, and the system level security access called 
the eForm User group (user, ACTR, DCTR, RESFOR), and account status (watchstander. 
active, temp account (training and visitor), locked, stale, disabled, and deactivated). 

3.1J.I.C 

The ACTR shall receive a confirmation or error message once the request has been 
submitted. All fields are required to contain data, and therefore validation that data exists in 
each field is required. An error message should include an explanation of the error and what 
should be done to resolve it (i.e. error! data is required in the command location field). 

3.1J.2 Request Password Reset 

Develop a view that filters data in the database and returns a list of all the active 
account names and login identifications for all users assigned to a specified ACTR. The 
ACTR shall be able to mouse click on a specific login id and the details of the account will be 
provided. A password reset button should exist on the page that, if selected, will 
automatically send a request to the help desk to reset the password for the specified user. The 
ACTR should receive confirmation once the password reset option is selected. 
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3.1.3.3 Search MAC Account History 

The ACTR should be provided a view that requires input of the user’s last name, first 
name, and middle initial. Once this information is entered, the system should return a list of 
all names that match the user that was entered and should include the command location 
history for each of the accounts that are returned. 

3.1 J.4 Order a new seat 

A view is required that allows the ACTR to order a new seat and the associated 
peripherals. Any requests of this kind must be submitted by the ACTR to the DCTR for 
approval. The DCTR, in turn, will accept the MAC request and forward the request to the 
supervisor using the management tool. 

3.1J.4.a 

The view should require the user to manually populate as few fields as possible. 

Data that is common to the ACTR (i.e. POC last name, first name, rank/rate, phone, email 
address, installation location address info) should be auto-populated in the prospective entry 
fields. This will reduce the time required to submit the request and minimize data entry errors 
which could cause the request to be rejected. The page should also include a pre-populated 
list that includes contract specific information (i.e. Seat CLIN. Option, CLIN, Sub Option 
CLIN etc.) for easy selection by the ACTR. Besides the physical address, the installation 
location shall include the building number, floor, room number and cubicle. 

3.1J.4.b 

Once all the information is entered, the ACTR shall be able to preview the order in a 
separate view. An option shall be given to confirm that the information is accurate or to 
return to make edits to what was entered. Once the accuracy of the infonnation is confirmed 
and the request is submitted, the ACTR should be redirected to the page that allows a review 
of all seats (current and pending). 

3.1J.4.C 
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The ACTR is required to make requests for upgrades to any of the existing seats that 
were previously installed. A page shall include a list of all seats that are controlled by the 
specified ACTR. Additional information about each seat shall include the CLIN, any 
option/sub-option CLINs and the billing start and end date. 

3.1.3.5 Request an Upgrade to an existing seat 

The ACTR shall have the ability to select the Seat ID that requires the upgrade and a 
page with all the information about the seat shall be displayed. 

3.1J.5.a 


A pre-populated list shall be used to select any upgrades and the point of contact 
information should be auto-populated with ACTR common data (i.e. last name, first name, 
rank/rate, phone number, email address. 

3.1J.5.b 

This action is chargeable and would require approval by the authorized submitter 
(DCTR) prior to submission to the contractor’s supervisor of the SRM team. 

3.1.3.6 Request a Physical Seat Move 

Any requirements for seat relocation must be performed by the contractor. The 
ACTR is required to submit a request that includes the seat information, current location, and 
new location information to the contractor before the physical move will occur for any 
previously installed seats. 

3.1J.6.a 

The ACTR shall have the capability to first review a consolidated list of all seats 
under their management responsibility. The list should allow the option to mouse click on 
the desired Seat ID to display specific information about the seat including the current 
location. The ACTR shall be allowed to enter the new location directly into the page and 
submit the request to the DCTR for approval. Once the request is reviewed and approved, the 
DCTR will then be able to forward the request to the contractor for resolution. 
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3 .1.3.7 Turn in any excess seats 

The ACTR is required to return seats that are no longer used or required to the 
contractor for redistribution. The ACTR requires the capability to submit a request for all 
excess seats to the contractor. 

3.1.3.7.a 

A page shall be created that will list all the seats under the purview of the ACTR and 
allow selection of the Seat ID for all equipment that is desired to be returned. Selection of the 
Seat ID should reveal a page that provides detail about the seat to include the seat CLIN, 
option/sub-option CLIN, NMQ Seat ID, classification, service date, UIC and current 
location. The ACTR shall be given an option to send an automated requested to the 
contractor supervisor to have the seat removed. A confirmation message shall be received by 
the ACTR confirming the request for equipment removal has been forwarded to the 
contractor for action. 

3.1.3.8 View/Edit Seat Data 

Provide a view that includes detailed information about each seat that must be 
managed by the ACTR. The page should include: 

■ Seat ID, CLIN Number, Type of Seat or Service, any Option CLINs that are 

attached to the seat and a description of them, the service start and end data, the 
price, and the status (pending or installed). 

■ The automatic calculation of the total dollar amount for all MACs that have been 

installed. 

3.1J.8.a 

The ACTR shall be able to select the Seat ID of any seat that requires editing. 

Editing allows the ACTR to administratively make changes or corrections to information that 
exists about each seat and the associated peripheral hardware. Selecting the Seat ID should 
display the following information about the seat: Seat CLIN, Option/sub-option CLIN, 

NMCI Seat ID, Classification, Service start/end date, and UIC. Information about the asset 
location should also be displayed to include the address, base, city, state, zip code, building 
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number, floor, room number, and cubicle. Lastly, computer information should also be 
editable to include the Asset ID, Computer Name, Service Tag Number, Manufacturer’s 
Serial Number, Data Installed, Manufacturer’s name and install notes. Any changes made 
shall be previewed by the ACTR first before it is saved. The ACTR shall be provided an 
option to confirm the changes or to return to make additional modifications before the 
modifications are saved. 

3.1.3.9 View/edit hardware and peripherals 

Just as with seats, the ACTR may be required to administratively edit the information 
previously saved for peripherals and other associated hardware. These modifications could 
be a result of inaccurate data entry, equipment relocation, or simply adding information that 
was not previously known. 

3.1J.9.a 

A view is required which allows the ACTR to make these administrative changes to 
the information. By selecting the Seat ID, the ACTR shall have the ability to view all 
hardware and peripherals that are associated with a seat. The ACTR will then be capable of 
selecting the peripheral that requires editing and be able to modify the following information: 
hardware type, Asset ID. Service Tag Number, manufacturer’s serial number, manufacturer’s 
name, model and installation date. 

3.1.3.10 Validate eMarketplace Invoice 

Provide a page that includes detailed information about each MAC (billable or non¬ 
billable) that must be managed at each reporting level for auditing purposes. The page should 
include: 

■ Seat ID, CLIN Number, Type of Seat or Service, any Option CLINs attached to the 

seat and a description of them, the service start and end data, the price, and the 
status (pending or installed). 

■ The automatic calculation of the total dollar amount for all MACs that have been 

installed. 

This data should be used to verify that the information that is billed in eMarketplace 
corresponds with the data that is in this tool. 
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3.1.3.11 Administratively Add Seats 

The ACTR will initially populate the tool with hardware, seat, and account data if the 
command has cutover to NMQ prior to this web-based tool reaching full operational 
capability and an interface for entering this information is necessary. 

3.1.3.11.a 

The first page should permit entry of seat-specific information including the Seat 
CLIN, option and sub-option CLIN, NMQ Seat ID, classification, and Service start and end 
date. The page should allow the ACTR to use pre-populated list menus to select the Seat 
CLIN, option/sub-option CLIN; and seat classification. The ACTR will have to also enter the 
Seat ID and the Service start/end dates. Viewable calendars shall be used to auto-populate 
dates in the date fields. 

3.1J.ll.b 

Once the seat information is entered and saved in the Functional Feature 3.11 .a the 
next view should allow the ACTR to enter location information about the asset that was 
entered. The asset location should include the address, base city, state, zip code, building 
number, floor, room number, and cubicle. The address fields shall be auto-populated to 
match the location of the login ID, yet still be editable for making modifications. State 
information shall include a system generated list of all states allowing the ACTR to select the 
appropriate state. 

3.U.11.C 

The next view shall allow the ACTR to enter specific seat information into the 
system. The information includes the NMCI Asset ID, computer name, service tag number, 
manufacturer's serial number, date installed manufacturer’s name, and a comment area to 
record any installation notes. 

3.1.3.114 

Once the submit button is selected from Feature 3.11 .c, the ACTR will be able to 
view all information entered and add peripherals to the seat. Specific infonnation that must 
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be entered for a peripheral is the hardware type (monitor, blackberry. Common Access Card 
reader, scanner, digital camera, docking station, Uninterruptible Power Supply, laser printer, 
and inkjet printer), NMCI asset ID, service tag number, manufacturer’s serial number, date 
installed manufacturer’s name, and model. The ACTR shall be able to view the entire list 
that composes the “hardware type” and select the appropriate one without typing the 
information into afield. 

3.1J.ll.e 

The option must be given to allow the user to add as many peripherals as required 
and being able to preview them as they are added. This same view shall give the ACTR to 
option to submit the request to administratively add all equipment to the inventory 

3.u.ii.r 

Once all equipment has been entered and the ACTR administratively submits the 
request to add it to the system, the ACTR shall be able to make edits to what was entered. By 
viewing a summary of all assets entered in this instance, the ACTR shall have the option to 
click on or beside any asset and select the edit feature. The edit feature will recall and auto¬ 
populate the information about that asset by displaying the same fields identified in functional 
features 3.9 and 3.10. 

3.1,4 DCTR Tool 

The DCTR is the authorized submitter and must approve all chargeable transactions 
before they are forwarded to the contractor for action. The DCTR’s role is to review the 
request for accuracy and completeness before it is sent to the contractor supervisor and 
ultimately the SRM team for action. Therefore, all requests that require a MAC must be 
automatically forwarded to the DCTR once the ACTR submits the request. 

3.1.4.a 

Construct a view with a summary of all requests awaiting the approval of the DCTR. 
This view should include the last name, first name, middle initial, and base for all account 
MACs. The UIC, MAC number, SeatID, and request type (new order, modification to order) 
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shall be included for the seat/hardware MAC information. The account and seat/hardware 
MACs should be designed as separate ledgers but on the same view. 

3.1.4. b 

The DCTR is required to view the details of each MAC request for accuracy and 
completion. Once the DCTR has completed the review process, the MAC request should be 
either forwarded to the SRM Team supervisor or returned back to the ACTR for correction. 
The DCTR will be given the option to accept, return, or reject the MAC request. 

3.1.4. C 

The account MAC details page should include the user’s last name, first name, 
middle initial, log-in ID, CLIN type, user group, billing UIC, major claimant, base, task 
order number, network classification (unclassified, classified), command point of contact, and 
command address. The seat MAC details page should include the Seat CLIN, option/sub¬ 
option CLIN, classification, billing UIC, asset location address information, and installation 
point of contact information. DCTR should have the ability to make comments on all 
requests before they are forwarded. 

3.1.5 Contractor Management 

The contactor is responsible for completing all requests provided by the government 
technical representatives. All chargeable requests are forwarded from the authorized 
submitter (DCTR) to the contractor for action. Non-chargeable requests are forwarded 
directly from the authorized submitter (ACTR) for action. 

3.1.5. a 


The contractor’s tool requires hierarchical separation between the supervisor and the 
SRM teams. The information that is accessible to both is based on the privileges established 
with the user login ID. 

3.1.5.1 Contractor Supervisor 
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The Supervisor has overall management responsibility for all MACs submitted by the 
authorized submitter. Subsequently, the supervisor has sole authority to view all MACs and 
decide which SRM team will be responsible for servicing the MAC requests. 

3.1.5.1. a 

A page is desired which provides a list of all MACs that have been accepted by the 
contractor. The list should include the MAC number, the MAC submission date, the Type of 
MAC (user or seat), the CLIN number, the base, and the details of the MAC. The list should 
be sorted by MAC number and then MAC submission date to assist with fast retrieval of 
information. 

3.1.5.1. b 

Clicking on the details of any MAC shall enable the supervisor to view specific 
information about the seat or account. Seat MAC’S should include the Seat CLIN, 
option/sub-option CLIN, classification, billing UIC, asset location address information, and 
installation point of contact information. Account MAC details should include the account 
CLIN, classification (unclassified or classified), the billing UIC, specific user information 
(first name, last name, middle initial, rank/rate, login name, phone number, UIC, description, 
and site code), and command point of contact information. All MAC’S should include a 
comment block for the supervisor to provide commentary to the servicing team. 

3.1.5.1. C 

The Contractor should have to ability to view each MAC and assign a MAC to the 
team of choice. The options to accept a MAC and assign it to a team number shall include a 
user-friendly pre-populated selection list to minimize data entry. The list should include an 
option to select Team 1, Team 2, Team 3, and Team 4. 

3.1.5.1. d 

A view is also required for the supervisor to track the status of all MACs that have 
been assigned to each team. This view should provide the team number (i.e. Team 1) that has 
been assigned the MAC, the MAC number, the MAC Type (new order, new user), the CLIN 
number, the MAC submission date, the MAC status date, the MAC status (working, assigned, 
accepted), the command location (base), and any comments by the team. 
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3.1.5.2 Contractor SRM Teams 

The SRM team receives its work assignments from the supervisor. Once the 
supervisor assigns a task to a team, the team must be able to acknowledge that it has begun 
working the tasks and must provide feedback when the task is completed. 

3.1.5.2. a 

A team view is required that provides a summary of all MACS assigned to the team. 
The summary information should include the MAC number, the type of MAC (new seat 
order, new user), CLIN number, date the MAC was assigned, status (working assigned), the 
location of the MAC (base/command), comments from the supervisor, and a link to the MAC 
details. 

3.1.5.2. b 

Clicking on the details of any MAC should enable the team to view specific 
information about the seat or account. Seat MAC’S should include the Seat CLIN, 
option/sub-option CLIN, classification, billing UIC, asset location address information, and 
installation point of contact information. Account MAC details should include the account 
CLIN, classification (unclassified or classified), the billing UIC, specific user information 
(first name, last name, middle initial, rank/rate, login name, phone number, UIC, description, 
and site code), and command point of contact information. 

3.1.5.2. C 

The team should be provided with the ability to change the MAC job status (working 
or completed) via user-friendly pre-populated lists that allows the user to select an item to 
minimize data entry. Any status changes should automatically update the respective 
supervisor’s automated ‘track status log’. All MAC’S should include a comment block for 
the supervisor to provide commentary to the servicing team. 

3.1.6 RESFOR Management 
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A view is required that will provide theRESOR ClRs with the account and seat total 
for all RESFOR lower level technical rqrresentatives. These totals are required for the 
purpose of auditing acquired seat and account requirements and for invoice validation. This 
view will also allow for planning of future seat and account requirements. 

3.1.6.a 


The account totals shall be listed separately from the seat totals for easier view and 
reference by the user. The accumulated seat and account totals shall include the following 
categories: 

Account Audit: 

■ Total Non-Billable Accounts 
• Total Billable Accounts 

■ Total Free Accounts Derived from Seats (unclassified) 

■ Free Accounts Unoccupied 

■ CLIN 0024’s needed 
Seat Audit: 

■ Total Seats Installed 

■ Total Seats Awaiting Installation 


4. Security Requirements 

System Environment: The CNRF Navy and Marine Corps Intranet Enterprise 
Management Tool will be hosted on an NMCI provided network and will employ all security 
controls germane to NMCI networks. Access to the system will be limited to registered users 
of the NMCI network. 

System Interconnection/Information Sharing: This application will interconnect 
or share information with the following applications: 

NMCI Enterprise Tool (NET) primary 
Electronic Marketplace (eMarketplace) 

Service Request Electronic Form (SREform) 

MS Outlook Global Address List (GAL) 
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MS Active Directory 

Ultimately, the application should integrate the data in NET. SREform, and Active Directory 
into one tool. 

Written authorization (MOUs, MO As) will be obtained from the application’s 
cognizant authority prior to connection with other systems and/or sharing sensitive 
data/information. It will detail the rules of behavior that must be maintained by systems. 

General Description of Sensitivity: 


Evaluation 

Description 

Medium 

Confidentiality: The system contains information that requires 

protection from unauthorized disclosure. 

High 

Integrity: The system contains information that must be protected 

from unauthorized, unanticipated or unintentional modification. 

High 

Availability: The system contains information which must be 

available on a timely basis to meet mission requirements and avoid 

substantial losses. 


Application Users: Primary users of the system and their associated hierarchy are listed in 
the graph below. Users will be granted access rights to the system commensurate with their 
assigned billet (ie. ACTR, DCTR, RESFOR). A user assigned a RESFOR account is an 
Echelon III user and will therefore have privileges to view all data within the system. A user 
assigned a DCTR account is an Echelon IV user. Echelon IV users are assigned authority 
over a specific region (i.e. Northeast, Southwest) and will have authority to view all data 
within their region. ACTR accounts are typically assigned at the Echelon V level. These 
accounts are command accounts and they have authority over users within their command. A 
detailed summary of user functionality is included in section 2.3 of this document. 


Developed by N61, IT Project Management Office 


141 












CNRFC Navy Marine Corps Intranet Enterprise Management Tool Functional Specifications 

Page 24 of 30 


Draft 



User Authentication: All users will be uniquely identified by use of a registered user id and 
secret password. Group or shared ids will not be used. Passwords will meet the following 
usage, construction and change requirements: 

The password will not be the same as the user id 

Passwords will never be displayed on the screen 

Passwords will be a minimum of eight (8) characters and consist of mixed alphabetic and 
numeric characters. Passwords will not consist of all numbers, all special characters, or all 
alphabetic characters 


5. Data Conversion Requirements 

Currently the management tools provide little automated interface with the various existing 
systems enumerated in the previous section. In most cases the data is consolidated manually by 
importing data through an intermediary application such as Microsoft Excel or Access. Once a more 
robust interface capability is developed into the Management Tool, a series of MOUs and MOAs will 
be established to govern the exchange of data/information between the systems that will remain 
separate from the newly developed web-based tool. 

6. Performance and Response Time Requirements 

There are currently seven regions established within the Naval Reserve Forces Command 
(NRFC) with an established hierarchy in each region of approximately 30 users. This system could 
potentially have more than two hundred users accessing the system simultaneously. The system’s 
server platform and network capacity will require close monitoring as the Management Tool is 
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implemented throughout NRFC to insure expected system performance requirements are met. The 
selected DBMS should be able to handle concurrency measures to maintain availability and integrity. 
Shuffle application should be stored procedure to increase speed of processing. Finally, all views 
should be optimized with an automated analysis of indexed fields to ensure that common views are 
loaded rapidly. 

7. Platform Dependent and Installation Requirements 

Users can access the Management Tool via the Internet utilizing Microsoft Internet Explorer 
or Netscape Navigator with 128-bit SSL encryption. The Database Administrator and Developers are 
required to use the Client version of Oracle Discoverer and Oracle Discoverer for Administrators. 

The client software will run on Microsoft Windows 2000 or Windows XP 

8. Localization Requirements 

Not Applicable. 

9. Parallel Testing Requirements 

The Management Tool is currently a test system. Parallel testing requirements will begin to be 
addressed once a decision has been made regarding the potential replacement of existing legacy 
systems. Once legacy systems are replaced by the target application, no other systems will run in 
parallel. 

10. Cross System Interface Requirements 

Initial database should be populated by mapping fields from the active directory and extracting seat 
data from net. A grace period should be given for ACTRs to edit, add and delete seats and accounts 
to establish an accurate baseline. Once all changes have been made all direct link to active directory 
should be ceased. Further, initial population of the database may be accomplished with an upload 
function of existing data (an XL spreadsheet or Access Db). 

Another primary interface consideration is the interface with Remedy Helpdesk. The SRMAC team 
supervisor pages should generate trouble tickets which are sent or written directly to the Remedy 
database. This interface may be a direct field-to-field translation, and XML transform, or even an 
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email sent to the helpdesk URL. In any event the site should be tailored to provide all of the 
necessary fields to remedy in order to act on and track MAC service requests. If feasible the MAC 
table could be initially populated with data in Remedy to show a MAC history link to user profiles, 
and seats. 

11. Data Archival, Backup and Recovery Requirements 

The system administrator will perform daily incremental backups with a full system backups 
performed weekly. The backup software will be capable of performing a backup verification of all 
media on a weekly basis. Backup media will be archived quarterly and yearly. Recovery backup 
media will be stored off-site. 

As the system hard drive reaches capacity we can either archive the older data via digital tape 
or increase the capacity of the hard drives. The system administrator will closely monitor disk 
capacity over the first year of system use to ensure adequate storage resources are available. 

12. Reporting Requirements 

User may require the added functionality to export table views in an XLS format. Reports 
required by commands for accountability and billing may be required locally. Site should have the 
ability to extract that data for locally generated reports and walk through verifications. 


13. Project Flexibility Matrix (*Project Sponsor will complete) 

EXAMPLE: 

For a project to succeed, there are 3 variables that affect how quickly aproject can be completed: Resources, 
Schedule and Functional Feature (see diagram below). One of the sides of the triangle must always be 
flexible to achieve success. For example, if the client has a fixed number of resources (people that wotk on the 
project) and their schedule has been set in stone, the Functional Feature set must be flexible. This means that 
they must be flexible to drop some Functional Features to make the pre-determined date with that number of 
resources. Working together, the team places a check mark in the appropriate column for each of the project 
variables. The columns are defined as: 

• Inflexible. Mark 2 items that are inflexible. For example, if the cost and ship date are set in stone, make 

Resources (Cost) and Ship Date as Inflexible. Only 2 items can be inflexible, the last item must be flexible. 

• Flexible. Mark one item as flexible. For example, if you are flexible with the Functional Features that are 

included in the project, mail: Functional Features as Flexible. 
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Project Trade-ofT Matrix 


F irn ct ion al F eatur e s 

Resources 

(Cost) 

Schedule 

Inflexible 

Flexible 

ACTR Features 





3.1.1 





3.2.2 





3.1.3 





3.1.4 





3.1.5 





3.1.6 





3.1.7 





3.1.8 





3.1.9 





3.1.10 
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Project T rade-off Matrix 


DCTR Functional Features 

Resources 

(Cost) 

Schedule 

Inflexible 

Flexible 

3.2.1 





3.2.2 





3.2.3 





3.2.4 





3.2.5 





3.2.6 





3.2.7 





3.2.2 






Project T rade-off Matrix 


Contractor Functional 

Features 

Resources 

(Cost) 

Schedule 

Inflexible 

Flexible 

3.3.1 





3.3.2 





3.3.3 





3.3.4 






A team should use the project trade-off matrix as a reference when making decisions. The matrix is not intended 
to show absolute priorities; it is merely a tool to facilitate communication and understanding. Most important 
for the project team is that the matrix shows areas in which the customer is willing to compromise. Make sure 
that no row or column in the project trade-off matrix has more than one check mark. Any other combination 
poses serious risk to the project and must be accounted for explicitly in the risk management plan. 

In order for a team to be successful, at least one check mark must be in the “flexible” column. This means that 
the team owns one side of the triangle (that is, owns at least one variable) so that the team is empowered to 
manage change and risk, and is therefore positioned to achieve success instead of failure. 

14. Stack Ranking of Functional Features 


To ensure that items are worked on in order of importance, stack rank the Functional Features with the lowest 
stack rank being most important and the highest stack rank being least important. This will allow the 
development team to focus on the important items and to manage risk. 


1 Rankins 

Req # 

Functional Feature I 

11 

| 3.1.1 

| Usability 

Li:_1 3-1-l.a _1_1 
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3.1.3.2 

Request Password Reset 


3.1.3.5.a 

Request an Upgrade to an existing seat sub-function of p re-populating the 
list 


3.1.3.7 

Turn in any excess seats 


3.1.3.7.a 






15. Roles and Responsibilities 


Chart below displays high-level roles and tasking by life-cycles phases. N6 Development team consists of 
several skill sets of representatives from several N6 Divisions. 


Life Cycle 

Role 

Responsibility 

Planning 

Setup hardware /software for 
Development 

N6 Development Team 


Functional Specs 

N6 Development Team / Functional PM/ PM 


Detailed Design 

N6 Development Team/ Data Manager 


Test Design 

N6 System Test Lead 


Development Project Plan 

N6 Development Team 


Test Project Plan and Budget 

N6 System Test Lead 


Overall Project Plan 

N6 Project Manager (PM) 

Development 

Data Management /Coding 

N6 Development Team 


Unit Testing 

N6 Development Team 


System Test - Test Cases 

N6 System Test Team 


User Test - User Test Lead 

Functional PM/ User Test Team 


User Test - Test Cases 

Functional PM/User Test Team 


Setup hardware for System Testing 

N6 System Test Team 

System Testing 

Migration of code/database from 
Development to System Test 

N6 Development Team 


Populate test database for System Test 

N6 Development Team 


System Testing 

N6 System Test Team 


Bug Tracking / Triage 

N6 System Test Lead, Development Manager, PM 


Drops for reiteration of fixes 

N6 Development Team 

User Acceptance 
Test (UAT) 

Migration of code from System Test to 
UAT 

N6 Development Team 


Populate test database for UAT 

N6 Development Team 


UAT Testing 

Functional PM/User Test Team 


Bug Tracking / Triage 

N6 System Test Lead, DM, PM, Functional User Test 
Lead 


Drops for reiteration of fixes (must go 
back through System Test) 

N6 Development Team 

Implementation 

Migration of code from LTAT to 
Production 

N6 Development Team 

Execution 

Operating- Functional Users 

Functional Users 

Closing 

Lesson Learned 

PM/A11 Stakeholders 
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Detailed Design 

Owners and List of Contacts 


Name 

Email 

Phone 

Role 

Gwen Graves 

omaraves®nos.edu 


Project Manager 

Development Lead 

Gwen Graves 



System Test Lead 

Gwen Graves 



Production Support Mqr 

Justin Rumps 

irrumps($nps.edu 


User Test Lead 

Ian Denny 

imdennyOnps.edu 


Developer- EDS Supervisor 

Dieter Jahn 

diahn®nps.edu 


Developer- EDS Teams 

Trey Blacklock 

wtblackl(©nos.edu 


Developer - Seat 

Management 

Chris Marvin 

cemarvin(®nps.edu 


Developer-Account 
Management 

Chris Marvin 



Data Base Administrator 


Signoffs 


Phase 

Name 

Date 

Signature 

Detail Design 

John Doe, PM/DM 

Joe Tester, System Test 

Lead 

Jane Prod Support, 
Production Support Mgr 

Joe User Mgr, UM 

Joe Functional Sponsor 

xx/xx/xx 
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1. Summary 

This application is a web-enabled database. It has a standard 3-teir architecture of client 
browser, application server and database. 


2. Hardware Requirements 

Server should have sufficient storage to house database. With 65K accounts, the storage space 
is about 405 Mb. Consider twice that to capture MAC event history for each account. Currently 
being served on a Dell Poweredge XXX system with XX Gb RAM and XX type hardrive. Consider 
a RAID 5 array for application and database prevent data loss and increase drive access speed. 
Additionally, best practice would be to have the database and the applications residing of 
separate platforms in the case of system failure. Client computers with sufficient graphics 
capabilities to support 256 colors. 


3. Software Requirements 

System developed using Macromedia Dreamweaver MX2004 and JASC paint shop Pro V3.5 for 
graphics. Database currently resides in Microsoft Access, but do prevent concurrency and speed 
issues, it should be migrated to SQL server 2000 or equivalent. In orderto use a non-Microsoft 
database, significant changes would have to be made to the prototype. The site is hosted on IIS 
5.0 using ASP on a Server 2003 OS. The client requires Internet Explorer V5.0 with Microsoft 
VM and cookies enabled. Adobe reader4.0 is necessary to view documentation and CLIN lists. 


4. Presentation Layer 

This section describes all the screens and reports needed to deliver all the functional 
requirements. Included are screen descriptions, screen shots, report descriptions and report 
shots. The client should understand that the final product may not be exactly as listed here but 
the functionality will stay the same. During coding, we may merge or separate screens to achieve 
a nicer user interface and to promote reusability of components. 
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4.1 Screens 


4.1.1.1 In-Process new users “Search Accounts for Profile” 
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Service Request eForm 
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Search Accounts for Profile 
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Description 

This form allows the ACTR to enter the name data of a prospective new 
user as it appears on a government-issued ID card. The purpose of this is 
to check for an existing account to prevent the creation of a redundant 
account 

Security Group 

ACTR. DCTR 

Data 

Last name, First name, and Middle initial are entered in the corresponding 
form boxes as they appear on the prospective users ID Card. 

Actions 

The “Clear” button allows form to be wiped clean in case of an error. The 
“Submit" button processes the data in a search function to check for 
existing accounts that match the input name. All accounts or specific 
types of accounts may be searched by using the “Accounts To Search” 
drop down menu. 
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4.1.1.2 In-Process new users “Search Results” 
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Description 

The search results screen displays accounts that match the name entered 
in the “Search Profiles" page. The results may or may not be a correct 
match for the prospective new users due to some users having names in 
common. To determine if the prospective new user is a match to one of 
the accounts the “History" link will display the MAC history for the account 
in question allowing a user to determine if the account matches previous 
duty stations and time frames. 

Security Group 

ACTR, DCTR 

Data 

Data on this page is derived from a query on the input user name from the 
“Search Profiles” page. 

Actions 

Profiles that appear on this page can be checked for a match to the 
prospective new user, link to update new information if a match is 
established, or link to create a new user profile if required. 
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4.1.1.3 Update User Profile 
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Description 

Used to update user profile informabon 

Security Group 

ACTR DCTR 

Data 

The data dnptayed initially on this screen a the nformabon currently In the 
user profile table for the user in question Data for the "UtC" drop down 
menu is provided from the "Adrvrties' table Data for the “Type" drop down 
list is Is hard coded in the webpage 

Actions 

Any data on the page can be modrfied and Submitted update the user 
profilo tablo A "Clear Form" button has been provided and can be usod Co 
clear all data on the screen before updating 
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4.1.1.4 User MAC History 



Description 

This page displays MAC history from the MAC Table to assist in te 
determination of an account's ownership. 

Security Group 

ACTR. DCTR 

Data 

Data on this page comes from stored data in the MAC table. 

Actions 

None. Data is only viewable. 


4.1.1.5 Add New User Profile 



Developed by NPS, NMCI Management Prototype Team 


155 










































Detailed Design 


Page 8 of 43 


Description 

This screen is used for the input of new user data. 

Security Group 

ACTR, DCTR 

Data 

UIC field data comes from the Activities table and is default set to the UIC 
of the ACTR entering the data for the new users however, it may be 
changed to any UIC in the database. 

Actions 

Form fields are completed as required and are submitted to enter data into 
a new user profile and proceed to the creation of a “New User” MAC 

request. 

4.1.1.6 New User MAC 
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Description 

New users MAC request to be submitted through the chain of approval for 
activation. 

Security Group 

ACTR, DCTR 

Data 

New User data comes from the user profile table. All default command 
data comes from the activities table. 

Actions 

Complete all fields as required and submit for approval. 


4.1.1.7 Accounts within a specific ACTR's UIC 



Description 

This page provides dual functionality by both listing the accounts for a UIC 
and providing a link to the account details and an option to reset the 
password. 

Security Group 

ACTR, DCTR 

Data 

All data is from the user profile table. 

Actions 

Select a user logon ID for more information. 
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4.1.1.8 Account Details 

i beb=zbz=ex=z=^b 

Q- >-0 •« • *i 




~3*J- — - 


Description 

Details on an indrvidual account 

Security Group 

ACTR DCTR 

Data 

Data is from the user proWe table 

Actions 

User profile tab*o data can bo vwwod and there is an opfcon to react the 
user s passwor d with the ’Password Reset* tx4ton 


4.1.2.1 Logon 



S«*vic* Rtoucsi iFc«m 



•-1 

I his «<fr is far fansnstnition pur|w««> »nlt 

II l« dnifiMtl la Aid in the rr^uirtmrnlt 4rftnMi>xi pmnt 
•ind is noi nir.tni ** a «ohit ina 


Description 

Enables Die umu to logon 

Security Group 

All 

Data 

logOnMame, password 

Actions 

Redirects user to home page based on eFormUse-rGroup 
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4.1.2.2 CookieWriter.asp 


Description 

Writes cookies based on the login. Cookies for U 1C, Log On Name, 
DisplayName and TFMod# are written to the users computer 

Security Group 

User, ACTR, DCTR, RESFOR 

Data 

Data is pulled from TbIUserProfile based on LogOnName 

Actions 

Automatically loaded and redirects to home page based on usergroup 


4.1.2.3 ACTR Home 


E* l* JX" | 


Service Request eForm 


ACTR TOOLBOX 


town wcti Vi*w Atttvc Actvuatt 

Kc'tacnmfwyr4.rt|t| How to ice which kcooq 

Start Whaii.j'Ji.iiftoh^v 


NMCI 


JE8L 


UNIT STATISTICS: 

Chooee a number beloie to trim detaili 


Order a rxw hariwirt if at Y»?tfE4s 5t*J>»t* 
p.e«Kit to nrmtittr Y«wflaSi turdwna/ fmtmtt 

Ktjati; iihvu;ti tcii m- 


Description 

List links to all of the functions that an ACTR needs to use. Has a unit 
statistics table to display totals for accounts, seats, billable, non-billable 
and all of the pending MACs 

Security Group 

ACTR, DCTR 

Data 

All count functions pertain to the UIC from the cookie. Billable Accounts or 
seat are not pending, deleted or disabled. MACs counted in pending or 
returned status 

Actions 

Count functions, read cookies, Display actions performed when arrived to 
from a previous page. 
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4.1.2.4 Order a hardware seat 

9> W fpatm I«* B* 


Service Request eForm 

Order a hardware seat 

Thu will submit a rtyuat to VMCX to physically deliver and ir 


NMQ 4p< 


t« a<lmlnlwn«v*ftt lilt tltt H*i 


ij'jia 

* 


Sen ant 00 01AA Red Seel 

Option CLIN No Additional Options 

SubOpbonCUN No Sub Opaonc 


CtnaScoban [yndawilulfli 

Ot dong DIC filSSl 

Installation 

Location: 


POC For Installation: 


•JUSTIFICATION: 

Provide uiitliari/utian details and i 


Wtm CUN should I 

Wlut.u.fa-aSppCUIiZ 

Wtouatgub-Opaw 

I-'IDI' 


• Adtoi 
' But 

• Cut 

' Stott 

• ZIP Cede 

• Budding# 

• Floor 

• Room Number 


K/MullmSi 

NfiCWATtMOWN 

fw 

13601-0247 
514 


• Cuticle 


Network Jack SKI BA 


| Pr«\—rrOrdw |[ Qo at Form | 


Lest Name benson 



Rank/Ratc No 

Phone fWlSSSIMH ~ 

hmjd Addrcfr tconbentootonav/mJ 


Identifies j wcekspace m a room 

Du a ursque letter for tech workspace when tta seat wB be metalled 

Optional (if brown) Prrt mostrryr, jack where the computer wdt connected to the network 

Jack numbers art located on a label by the pack 


Description 

To be able to put in the CLINs, options, locations and POC for installation 
of new CLIN 

Security Group 

ACTR, DCTR 

Data 

All pre-filled fields are initially set to the default data found in the 

UserProfile table joined with the Activities table for the ACTR/DCTR who 
has logged in. Drop down menus comefrom thethree CLIN_tables and 
the Command Table. 

Actions 

Submit button posts the form to the Order Review page 
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4.1.2.5 Order Review 


•1 http://131.170. 1 76.49 NMCI Sorvtco Roquet! end Account Management loolt Microtoft Internet f»plor*r I 

C*» t* lo* 0*. 0*0 

aa6P*e s- -i ■ . Q 

0 

Service Request eForm 

NMG 




Seat Order Review 


Mact Chany* (ha Order to adit thn rayuatt. 

SaUct Order Thi$ S*at to place the order utirh NMCI. 

| OiangeffittOdf | 


Seat: 

Asset Location: 

Justification: 

Seat CLIN OOOIM 

Adikns 

327 Muiun St Rewired for new sailor 

Option CLIN Non* 

Bate 

NPC WATERTijwN 

SubOptionCLIN Non* 

CAjr 

Wait down 

Clamficabon mkHmIW 

Stare 

NT 

BtlhrjgUIC tit 851 

ZIP Code 

nut-0747 

Task Order Mod « 

Bialrknx # 

55 

Installation POC: 

Floor 

2 

Room Number 

12 

Lajt Name ttcrrson 

Cubicle 

A 

F»st Name ttOB 

Network Jack 

5552* 2A 

Fank/Rate Na 



Fhone 0J1 555 lOW 



Entail Address icon&*nion®n*»vmil 




| Submit Thu Order | 


Description 

This page allows the user to preview their selections before they submit a 
request 

Security Group 

ACTR, DCTR 

Data 

All fields come from submitted form on seat_order page Hidden fields 
include the date submitted. 

Actions 

Submit button inserts the row into the Seat table and extracts the 
autonumber for the seat row, This number becomes a session variable 
identifying the seatNumber The page also creates session variable for 

POC name, phone and email because they may be different from the 

ACTR. The paqe redirects to the SeatProcessor paqe. 


4.1.Z6 SeatProcessor.asp 

Scraan displays only: Processing you: request. Pleasa Standby. 


Description 

Adds a row to the MAC table to begin the request for a new seat. 

Security Group 

ACTR. DCTR 

Data 

SeatNum is derived from session variable. POC information comes from 
the session variables All other data is read from the Seat table and 
written to the MAC table. The MAC table can store multiple actions on the 
same seat which may be at different locations 

Actions 

Seat Order data is written to the MAC table 
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4.1.2.7 Seat_Review 

FBWHMB1B 


o o 


fti / : €) - * 'i • , Q 0 


tr 


Service Request eForm 


N>vta 




Seal Review for UIC- 61851 

Thu pay thouu almofthaSaao included in your command, it can be mad to validate your monthly etdarbetplaco m< 
To admintcrratively add a toot to thit lia. click here. 


>A R«aS«» non 


Current Seats. Select a column header to sort. 


CUM S«MS«ivtet 

ckum «*a sea 

101 Vllwa 0001M RHStll 
T22»11t? OOOIM RMiM 
31frl6J7>l OMIM fiMM 
5:8033720 OOOIM RMSut 

50813032 0001*0 wwi«S«* 
761)8040 0001*0 VW\II«S«U 

?B?U7*rMI OOOI*C 8*1* S»M 

I. .:o : MM : m S«M 

JSbB 0001 AC Bu»S«»I 
46410071 OOOIM &ru»S«M 


Commeou voice s*ji 01727 

Swgctiablo Ciov-iOrd CannetMrUporiOe - 7>wn 

C ent Solution ' 

Swttfuen ClnMM C onnet*i*r VOS»» 0 * - Ouai n0 , n 

m ffmminn 


Fnwjwaw T»l«t outturn* 


3717001 307006 1 
6717003 6717001 I 


OBMI»ILlt*7C*»KillMt 10717001 101217000 1553 51 
(tewneit VWOOI1 W2004 *1.317; 


inue*n Mnnon« UMUtwtM wen Plug Semi 
0010*0 Pier vein Unt 


0006*0 *om»on4i Unties i *to Wtn Mug - 0 
i i'..' •• / i no ■.•'!, greenp.K!t||» 

0006M Ciettiflea W»u Plug (urmun t ccntro 


0 «» 8 *»t volte 
commurareBiwit (. 
Owonei uter Ceoi 


7737000 2717004 *102 IB 

5707001 5707000 *287 30 

41177002 4U7r2007 *512 00 


01107002 01107007 *1,00 


Description 

This page shows all of the current seats under the responsibility of the 
ACTR/DCTR. It contains what the seats are and calculates billing 
information based on the CLINs. It will optionally display the results of the 
last action such as adding, editing, or ordering a seat. The bottom of the 
page displays pending seats. 

Security Group 

ACTR, DCTR 

Data 

Seat data comes from the TbISeat joined with the CLIN tables. The 
previous action is based on the seatNumber session variable. 

Actions 

A custom script adds the columns to a variable as they are displayed in 
the repeat region. This enables a grand total for the command per month. 


Developed by NPS, NMCI Management Prototype Team 


162 



















Detailed Design 


Page 15 of 43 


4.1.2.8 Seat Selection 


Service Request eForm 


Select a Seat for UIC- 61851 



Thi-.fioi/r shows a Nat oftho installedSeats in your txnnrnund. Snhrct a seat to mrnd n hurtlu/anr workordirr to KtXS\ 
To administratively edit a seat without submitting a work order, dick here. 

Select a Seat ID to request a sub-option upgrade lor that seat. 


Current Seats. Select a link to sort the columns. 

NMCI Seoi IP 

Bw 

Building Rpon 

CUN Option CLIN 

SubOptlon CLIN 

Sturt Date End O.tte 

iuibiibb 

NK MObASCONIOKK U218 

|3 

0001AA IWObAO 

0014 

ii/28/2003 

li/28/2008 

13/U24UB 

NK NMCb 2/ DEI 172/ 

|8 

0005AD UUUbAO 

0027 

8/12/2002 

8/12/2007 

15585441 

NK NMCb 2/ Uhl 172/ 

[8 

OUOOAC OUUBAD 

0028 

1/24/2002 

1/24/2007 

1 58552b 

NK COMNAVNEO MIULAN1 DST A 

|3 

UUUBAB 001UAA 

0015 

8/28/2004 

8/28/2008 

1b122/UU 

NK NMCb 133 DET C 

fic 

0003AA 0010AE 

0027 

7/20/2000 

7/20/2000 

1b15B/B2 


I* 

0001AE OUUbAD 

0013 

8/18/2000 

8/18/2000 

1b485tibU 


|3 

0U05AD 0008AD 

0028 

12/2U/2003 

1272072UU8 

IBUb/72/ 

NK VTU 0218 

|9 

0U05AA UU1UAB 

0018 

4/14/200U 

4/14/2000 

2U4b4/4B 

NK VTU 0218 

|6 

0003Ab UUUbAb 

0020 

12/4/2003 

12/4/2008 

723B25bb 

NK VTU 0218 

|2 

0U38AC 001UAC 

0018 

3/23/2001 

3/23/2000 

23/b4U7 

NK MCbASCONlOKP 0218 

|4 

UUU'jAfc 001 OAb 

0018 

8/1/2004 

8/172008 

258801U4 


[10 

0001A7 001 IMA 

0030 

12/21/2001 

12/21/2000 

2b13bU5B 

NK COMNAVNEO MIDLAN1 DET A 

|4 

OUOlAb UUUBAB 

0024 

4/1 //2002 

4/1772007 

2bU7Bti1b 

NK NMCb 27 DE1172/ 

|3 

0038AC UUUBAJ- 

0020 

10/0/20UO 

1CI/W2000 

2/5B3U1 ‘j 

NK NAVHOSK P0K13MQU1H DEI N 

|7 

OUOtAb UUUBAB 

0014 

2/28/20U4 

272872008 

282U/52B 

NK MObASCONIOKK 0218 

[2 

0001 AC OOOBAC 

0011 

2///2002 

2/77200/ 

7B/B/48b 


|4 

0001AL 0008AH 

0024 

12/4/2002 

12/4/2007 

2B285333 

NK CCMNAVKEO MIULAN1 DET A 

[9 

0003AA UUUBAE 

0020 

3/W2004 

3/072008 

2H/118/2 

NK NMCb 2/DEI 172/ 

|i 

0004AB UUUBAB 

0010 

10/8/2002 

10/872007 

3UU331UB 

NK VTU 0218 

|5 

0005AC OOUbAT 

0017 

8/18/2004 

8/1872008 

31U1B7/B 

NK NMCb 2/DEI 172/ 

110 

0001AA 001OAE 

0018 

5/37200U 

57377000 

33211814 

NK VU7 0218 

|5 

0004AA U0U8AA 

0023 

1/2 S/2002 

1/20/2007 

34002383 

NK NAVHD3R PORISMOU1H DEI N 

[2 

UUUBAB UUUbAb 

0028 

3/4/2001 

3/472000 

30182/21 

NK COMNAVRED MIDLANI DEI A 

[3 

0038AC 000/ 

0014 

8/13/2000 

8/13/2005 




Description 

Allows the user to select a seat to upgrade, add hardware to, delete or 
move. Seats in any status other than installed cannot be selected i.e. if a 
sea! is not installed, you shouldn't be able to request that it be moved or 
deleted. 

Security Group 

ACTR, DCTR 

Data 

Data come from the Seat Table. 

Actions 

Columns can be sorted to easily find a Seat. The page displays a different 
header base on which function you are selecting a seat to perform. The 
seat ID creates a querystring SeatNumber which is retrieved by the 
subsequent page. 
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4.1.2.9 Seat Upgrade 


t* i* V- I— a» O' ■ 1' I , € L 0 


MJ'iJ 

tr 




Service Request eForm - 

A 

user: scott.benson 

UIC: 61851 

Request for Seat Upgrade or Change 

t/j* th* dropdown martin to thong* th* i flitted soot option!. 

!Jw* 'Submit Mom Orrfor- to hJ a hill.M« urorkander to NMCt/KDS. 

[ Return lo Seat Selection I 


Seat Selected: 

Current Location: 

CurnntCLiri KJUi«a 

Ad-*vit 327 Uullin St 

Seat CUN 0003AB Umltea SeMra Embetkeble 




OpBesCUN OfiO&AH Swnchahle Cteviatod CennectmV Upqredo • Deal CPU Solution • Norrftugiprditod Doptoyebiu Portnblo T 


SufcOpeonCUN 0014F tt edVi'deoTelecon»erenceVTCSeor 

ZIP Code 13801-0247 

NMCI Seat ID 48307560 

iluidng# 

Claiufir.abiKi unilMMlM 


Shwm Start Data 1117/2000 

Room Niank tt (■ 

Senvce End Date 1 117/2005 

Cuk«le mi" 

UIC most 


TFMod* KO0I5 


POC For Workorder: 

tanaon icutlMM3(NRCW0t.nto«i) 

Phot* 831 551 1804 

Emil 

Addien 1000 OensonWnevy rrW 

t 1 


tQDtee 



Description 

Requesting an upqrade or chanqe to an existinq seat. 

Securitv Group 

ACTR, DCTR 

Data 

Fields come from the Seat Table. POC comes from a join between the 

MAC table and the user profile table. 

Actions 

Submit button writes a new record in the MAC table with a MAC Status of 


pending. Redirect to the ACTR Home page with a querystring to show 
that a seat has been changed. 
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4.1.2.10 Request Seat Move 


I* l« S" 'I* 

Owaftoi. n 


o o 


ft / 'it €) : • * 4 ■ 


B 0 


i'a 

tr 

- 


Request for Seat Move 


Seat Selected: 

Sett CUN U00i*A 

Option CUN iwio«£ 

St4)Op»onCUN 0037 
NMCI Sett ID ItlJi'OO 

Seme Start Date 713413000 
Senvee End Date 7i3IU300S 


Current Location: 


ZIP Code 0601-0347 

Btald>vt« 


DIC 


61841 


Destination L 

Addrcff 


ZIP Code 
Building 8 
Root 

Room Number 
Cuticle 

Network Jack 


POC For Current Location: 


dttMiifllnSl lUtte 

NRCWATf RTCPAT4 phone 


tmiwort Mitt MM1 (NRC Wetalowi) 

■ 

icon betisoritStiosy mil 


POC For Destination Location: 

Us! Name tHiKon seal MM i (NBC W«rmto«m) 

Phone 831 4SStfl»« 

t-'relt 

,j. icon 68nion@n«vy mil 


Identifier a workspace in a room 

Ute a umnue letter for each workspace where thti teat will be mulled 

'Optional (d known) Pie-easting jack where the computer will be cormecud to the network 

Jack nuntberr are located on a label by the jack 


Description 

Request data nec. To physically move a seat from one place to another. 

Securitv Group 

ACTR, DCTR 

Data 

Initial data in the Fields comes from the TbISeat row selected from the 
seat select page and passed as a querystring. Also by the default data 
join of the Activities and UserProfile table based on the user LogOnName. 

Actions 

MAC is written to the MAC table with date submitted, pending status and 
“Request Seat Move" in details. 
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4.1.2.11 Seat Turn-in 


tk »» .. O '©'“'S' / : ' 0 


Service Request eForm 


Request tor Seat Turn-in 


OmnyuPOCoplnmairwcmaary. 

diet ’Submit Turn-in KoQtrttl ’ re uni a hilltblt workerJtr to mia/CDS. 


| Return to Seat Selection I 

Seat Selected: 

Current Location: 

Suet CLIN O0O5A4 

Addreti 5095 Ranijv Ri ) 

Option CUN 001 QA£ 

Bate NR NS* BAHRAIN OETC 

SubOpWTtJN 0012 

Coy LMVeotl 

NMdStuID laOttttt 

State nv 

Climficiaeo undented 

ZIP Code 09115-4119 

Service Strut Dare 5/17/2000 

Biaidmg# 

Senvce End Date 4/17/2004 

Flu of 2 

me »22*i 

Room Humber " 

TP Mod# 20011 

Cubicle C 

POC For Workorder: 


Lett Noe aort.Defc.WBDi 


Phone 8J1KS1004 

Enuul Adie. i doteciofl^nqvyml _J 

1 Submit Turmn Request 1 



Description 

Allows the user to turn in a seat. 

Security Group 

ACTR, DCTR 

Data 

All field come from the seat table. POC data defaults to a join between 
Activities and UserProfile on LogOnName and UIC. 

Actions 

Submit button writes a row to the MAC table with hidden fields specifying 
turn-in in MAC Details, and date submitted. 


■i ja 


Developed by NPS, NMCI Management Prototype Team 


166 





















Detailed Design 


Page 19 of 43 


4.1.2.12 Seat Details for pending seat 


I V 1,3 


amiijanaia.aiB'saaWiata—acioi; j^B *> 


Service Request eForm 

User: actr.2 
UIC: 61845 

Seat Details for Pending Seat 

| Hulum to Swot Kevrew | 

MAC/vri'tat n nrrmtiy tn Working a* of */ 

Seat Ordered: Delivery Location: 


Seat CUN 0M1M 

OptwoCUN now 

SubOpBonCUN Hum 

NMCI Seal ID 

ClainficatieB writHM 

Service Suit Dace 

Senate End Date 

TOC 61844 

TFMod# 

Addren SM #«•« A*» 

Bate NASPeamieiWr 

Stale H 

7i P Cede 06611 >741 

Buying# 1 

Floor 1 

Room Number 1 

Cubicle * 




Description 

This allows user to view, but not edit, any attributes of a seat in Pending 
status. It is used to verity requested edits, new orders, requests for moves 
ortum-ins. 

Security Group 

ACTR, DCTR 

Data 

All fields come from the Seat table with the exception of Status and status 
date which comes from the MAC table as the latest status on the 

SeatNum FK provided bv the session variable. 

Actions 

Return to Seat Prview links back to the seat preview page. 
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4.1.2.13 Seat Edit Details 


!» ,* W t) ' O i!l fl / '^ € - i i • ,00 

4)t«i>//i)t uo itt wi 


SERVICE REQUEST EFORM 




View Seat Details for NMCI SeatID: 31596084 


Save mg Sew Dew 


Seat: 


| £011 Si 


Asset Location: | eDIIloCTt0B | 


nnoiM 


Seat CUN 
OptwoCLIN COOWE 
SubOpeonOJN 0010 

NMCI Sen ID 3tii»u84 

CUn&nwn uncl«-.*wl 
Scrncc Suit Data in 00003 
Some End D*le UUH0SS 
tJIC WHO 

IT Mod# MOOU 


Saw*T*gNumber SJ60U3J2 


Meet 'snrr > 

Associated Peripherals: 


Description 

This page allows the user to choose data sets to edit which are associated 
with a seat. Also presents a link to modify the computer hardware or 
Peripheral hardware associated with a seat. This allows the user to see all 
information about a particular seat. 

Security Group 

ACTR, DCTR 

Data 

Information for fields comes from TbISeat and TbIHardware for the 
SeatNumber specified in the QueryStrinq. 

Actions 

Select to edit the seat, location, computer, or Add/edit/delete a peripheral. 
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4.1.2.14 Administrative Seat Edit 


» i* »- O ■ J 3 m K , h €? ;> * ■ . Q 0 

«] urn ito in wiimajpwgjKC.tet.xp'SwgMieg-inai 


Service Request eForm ^-J 


Edit NMCI SeatID: 75718027 

This urill n Til ihv tmimfmi sma! in four os mr inirrntoru, but will NOT submil a rm/uml to NMCX 


Seat CUM 

OODIAA v 


OpttoeCUN 

S*1oci nn Option (nui iKpitod) * Wlus n die option CUN’ 

SufcOpooaCUN 

Select a Sub Option (optional w Whar u the Sub-Option CLIN’ 

NMCI Seat ID 

17571802? 

8 Dqpls How do I find dm? 

CUMtiCXIOO 

unclusitied v 


Service Sten Date 

it/awooj 

_P 

Service Hod Date 

11/20/2007 

_J3 

1 SoveOongeeioSaet 

11 OeoiFom | 

| Cancel Ed* | 


_ • • 


Description 

This screen allows a user to edit the seat CLIN and seat ID 
administratively. The changes on this page will not generate a request to 
NMCI. This feature would be disabled when the initial database is 
completely populated with correct data. 

Security Group 

ACTR, DCTR 

Data 

All fields are from the TbISeat 

Actions 

User can edit all fields and save changes to the TbISeat. 
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4.1.2.15 Seat Location Edit 


* e 


0 0 


*$»"> I m __» Q fin 

CllUOluarJ «]UvdinllNn «) Ml«t g) 3K r4«ju' U3L ttWitmlWKM «jWn*jmHaU WO MusU Auau Wn In I10CS «]W*-I HmrMOJN nltou. Hrovmwt loo» 


Service Request eForm 


NMQ 


Edit the Seat Location foi NMCI SeatID: 50813032 




7h» Hat u assigns*! to t ho following physical location: 




Sou cun 

0001AB 




OptweCLIM 

OOlOAli 




SubOpBanCUN 

0023 




NMCI San ID 

50813032 




CUtri6eaBon 





Asset Location: 





Addren 

SI Mulkn SI 




but 

NRVTU02I8 v 




C«r 

Wawnown 




State 

NitwVork 




ZIP Code 

13801-0247 99999[-9999] 




Biddne* 





Floor 

11 




Boom Number 

[* 




Cuhck 

I 6 










<1C^« _ * 


Description 

This screen allows a user to edit the seat location administratively. The 
changes on this page will not generate a request to NMCI. This feature 
would be disabled when the initial database is completely populated with 
correct data. 

Security Group 

ACTR, DCTR 

Data 

All fields are from the TbISeat 

Actions 

User can edit all fields and save changes to the TbISeat. 
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4.1.2.16 Edit Computer 


y. i. B- J* O'O ft t W €! :.V •# 

Wt J/I51.1J0.P* MleVSWUnajSMI *dl «c.T<»il~».Mjrt*H)4J0 


SERVICE REQUEST EFORU 


E 0 


mg ^ 


Edit Computer associated with Seat: 31596084 

Lite this dialog to make administrative changes to this computer. Select Save ta commit the changes. 


Computer: 

NMCl At(«t IL> 
Computer Name 
Sennet T« Number 
Mfrc Serial Number 
Dale Intutrd 
Manufacturer 
Iniltl Note* 


I96497S45A 10 Plate tlvw do 1 Sad !rai ? 

ServortlJ22 ~j Dx computer's name on the network How.do.! Sn j the|7 

096046322 Tbe (trace tap arrogated with the computer. How .4/1 find Itttt 

966462164 

2/26/2003 ] MM/DD/YYYY 

D*4 

Opbccaal data you may ward to rtcre about tin computer 


|__S^rUw2os^to_Cuntpu]o*__| [ CluorForm I 


_ • • 


Description 

This screen allows a user to edit the computer information (service tag 
numbers, serial numbers etc.) for a valid seat. The changes on this page 
will not generate a request to NMCl. This feature would be disabled when 
the initial database is completely populated with correct data. 

Security Group 

ACTR, DCTR 

Data 

Fields come from TbIFIardware base on the querystring of seat selected 
from the previous paqe. 

Actions 

ACTR can change any field and submit the changes. Page returns to seat 
review with the seat number as a querystring. 
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4.1.2.17 Add Peripheral 


i* •i--' i -> u» O - © . 0 0 


i.-iaa 


lat in MAMSQWeutiM *M NardMtjwc'wAw'Mtmwibv-oixatvia^di * flco 
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4.1.2.18 Edit Peripheral 


'l.l"JHI...Ii.l.ll!.HI.I.|i...H..I'i|.' 'I H .B .. r.-l 
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4.1.2.19 Peripheral Deletion 

!> w 9" ’»*“•* !•*“ 0*0 .“!-]?£/ A 0 * «. * . Q 0 

<]K»«Ut lJJ lt6.MlWaWV.UjMr <MMt 


Service Request eForm ^ * “v’ 


Delete Peripheral 

will permanently delete the peripheral below. Ir dam not reorder or submit ant/ request* to NMCJ. 
| Caret Dat«B | 

Delete Peripheral associated with: (mwiju 


Hardwire Type Cmera 

HMC1 Auet ID 9987898 

Sinner Tig Number 87M59R 

M6‘> Senal Number akwoox 

MnuCicmrer Del 

Model X390 

InsUW-o Due 6l\*n 00? 

fP^l 



1• 

Description 

Confirms the request to delete a peripheral from association with a Seat. 


Does not send any request to NMCI. 

Security Group 

ACTR, DCTR 

Data 

TbIHardware provides all of the fields 

Actions 

Delete or cancel deletion. Delete deletes the row in TbIHardware 
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4.1.2.19 Administratively Add Seats (for initial population or RESFOR use only) 


tilhatin 


0 ■ 0 -J iS ft /■ * « 


. 0 0 


SERVICE REQUEST EFORM 


Thi'i urill add a ivat ta Hour uwf inuvnturu, hut urill NOT rai 
Hu pije t» uk 4 to tneuSy populute your «ut« duibaie 
To «dd KluW rwnol. yon need to fvbfl* «n offrl to 
You will ba able to add harwnra to rtu not m the non step 

BtftngUlC 62128 

SotCUH Select o Sew CLW 

Opttoo CLIN Select or OpOcci (nol required)_ 

SubOptionCUN Sutoaa! 

HMCIS.U ID 
ClwnScenon 

Service Start Dote 
Service End Dote 


ms 

a 


m 




Whit u the CUN foe dm ie«tt 

S wbuutta<wti'.UNt 
VRa l BiheSub OpnonCLa r 
S Dian Howl?! fed flu - ' 


Description 

Allows the ACTR to add a seat CLINs to TbISeat. This does not submit a 
request to NMCi. 

Security Group 

ACTR, DCTR 

Data 

CLINs and descriptions in the drop-down menus come from three CLIN_ 
tables. 

Actions 

Choose to add the seat or cancel. Adding a seat redirects to 
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4.1.2.20 Administratively Add Seat Location (for initial population or RESFOR use only) 


!> I* »•» 


; a* O ■ O l«j ft /■ •& €> : - * . S 0 


Service Request eForm 


m 




Assign the Seat to a Location. 

This will avsn/n ihir mt you just crmtwil I 

Sen CUM 0001 AA 

OpbooCUN 0006AA 

SubOpbonCUN OOliAD 

NM& Seat ID 9938)747 


BfingUIC 62128.62128 

Asset Location: 


Keem Number 
Cubicle 



• Ween* 

Description 

Assiqns the seat just created to a unit and address. 

Security Group 

ACTR, DCTR 

Data 

Data describing the seat comes from a query to the TbISeat. Default data 


comes from the userProfile Joined with the Activities table. UlCs are only 


UlCs that the ACTR is responsible for. 

Actions 

Save location or clear. 
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4.1.2.21 Administratively add seat computer. 


!> O' 'l—•* V* O' O -> fb / •&[ 42 ■ * d • J Q Q 


■ . . M , ,, 






SERVICE REOUEST EFORM 


•“ NMQ 



Add Hardware (Computer) to the Seat 





Thy. will link u ivmnu/vr to the tnut uou iw.f c rwahrtt, but mill NOT utbnur 

nvumr to NMCI 




V ou will be ablt to J4J u ptnpherak (llkt monitor, i earner. CAC rtadtr on the ne« pepej 




Seat: 


Asset Location: 



SeatCUH 

OOOIAA 

Addre.i 

995EMuuonSt 



OpbooCUN 

0006AA 

Ba* 

AAAV Woodbndge 



SubOpaonCUN 

001 SAD 

C*y 

SanJoie 



NMCI Scat ID 

nrnui 

State 

CA 



Clainficaion 

uncUrtdied 

ZIP Cod. 

05112-1699 





Bidding * 

44-14444 





Floor 

5 





Room Humber 

109 





Cubicle 

A 



Computer: 






NMCI Atict ID 

1 

10 Digit! ilowjp 

[find flat' 



Computer Name 


The computer’! name on the network Ilow do I_£n i tin; ' 



Senate Tag Number 


The rernce tag an 

ociated with the computer How do T firu! th.r? 


Mfr’f Seiul Number 


The manufacturer 1 




Date hauled 


MM/DD/YYYY 




Manufacturer 

Do* 





Itntal Hotel 


Upboaal data you 





Description 

Assiqns a computer to the seat 

Security Group 

ACTR, DCTR 

Data 

Data describing the seat comes from a query to the TbISeat. 

Actions 

Input the computer properties. 
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BffltM P*?ian 


Prat???* 4 ? 


4.1.3 Contractor Supervisor and Service Request Maintenance Team (SRM Team) View 
4.1.3.1 Contractor Supervisor Home 


Supervisor c.A*»ipi 


Tou Nm 29 ttACm to as % iyn 
4 wtaci 
24 Account MAC* 



Description 

Allows the Supervisor to v*ew a tost o(all pending MAC roquests By 
selecting the View Details hyperlink lor a specific MAC. the supervisor can 
view the spoetic details of the MAC and assign it to a Service Request 
Management (SRM) Team The supenraot also can view the status of 
any MAC previously assignod by clicking the appropriate hyperlnk on the 
summary page MACs are sorted by MAC number and then the date the 
MAC was submitted The totals lot the pending Seat and Account MACs 
are dynamically updated as the teams change the statue in the mac 

details page 

Security Group 

^ugervjso^ 

Data 

All fiolds are derived from TbIMAC 

Actions 

Supervisor can soft by column heading and -choose a MAC to assign to a 
team 


4.1.3.2 Supervisor MAC Detail s Review and Assign 
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P*K?1 9«43 


Supcrv ucor cStolm 


mi a 


.gffg^!>ygp.,j 


Account: MAC Bt\ 


i*,wr 



Cammrvw* POC 
r«ai «m 





r\_ - nilmli n — 

Description 

This page allows the Supervisor to view the details of a MAC selected 
from the Supervisor Homo Pago. The Supervisor can ass^n a MAC 
request to spocific teams lay selecting the team numbor from a list and 
selecting the update status option This page will display different fields 
based on whether the MAC Is an Account or a Seat MAC Comments can 
also bo added in the tort-entry box 

Security Group 

Supervisor 

Data 

All fields aro derived fromTblMAC and the key Is obtained through a 
session variable from the assignment page 

Aceon* 

Supervisor can modify the status, assign a loam a rd provide comments 

Th» page would interface with Remedy Help-Desk to generate trouble- 
tickets 


4.1.3.3 Supervisor MAC Status Review 
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Supervisor cReview 


NMO 


The following MACs have been assigned to Teams 

6 Seat MACS 

7 Account MACs 




T..m »—A« 


MAC Type Clwifltell.n 

aw 

MAC Submit Dm 



8m 

IewC.wwi.il 

1 

7 

New Oidei 

imrl.mf.r4 

0001AA 

3307003 

68 2003 

WarWmC 

NAS fWI lUlket 

C.— IW2 

1 

3 

New Oidei 

un.U..iljr4 0001AA 

3202003 

63 2003 

Uuikm, 

NRC Honolulu 


1 

3 

New Oidm 

un.U«.if>rd 0001AA 3702003 

652003 

Wat kmc 

B*«e 

I'm .nrLifll on ll' 

1 

U 

New Dm 

un>las(tfie4 

0026AF 

33-2003 

63 2003 

W.tkmc 

NAVTAC 


1 

17 

New U.e» 

unrl.t.ifi.4 

0026AF 

3702003 

652003 

Aiilcned 

NAVTAC 


1 

21 

New Diet 

un,l.«..f«4 0026AF 

613003 

68 2003 

Aiilcned 

NAVTAC 

8 Jaw lone me June eiieody! 

1 

2? 

New Dm 

nnrUmfi.4 0026AF 

6-2003 

6C2005 

632003 

Waikmc 

Workmc 

NAVTAC 

Tr.t of w-erkmc wrwl MAC 

1 

28 

New Utet 

u.nl.mf.,4 

0024.AF 

682003 

NAVTAC 


t 

39 


un.U>uf>r4 0O26AF 69 2003 

642003 

A..IBI..J 

NAVTAC 


1 

41 

New U.et 

ra.rU.idWd 0026AF 631 2003 

66 2003 

Atiigned 

NAVTAC 


2 

<• 

New Oide* 

un.U«if.»4 0001AD 3207005 

3 232003 

iViugu.il 

NRC Honolulu 


» 


New Mr 

umUa.if.r4 0002AA 3702003 

*22003 

Attignod 

NAS Pearl Haiku 



Description 

Provides the Supervisor with a summary view of all MACs that were 
previously assigned to a SRM team. The totals for the pending Seat and 
Account MACs are dynamically updated as the teams change the status in 
the MAC details page. 

Security Group 

Supervisor 

Data 

All fields are derived from TbIMAC. 

Actions 

Supervisor can return to the previous page and sort by column headers. 


4.1.3.4 Contractor Team Home 


Team cRcview 


NMQ ^ 


Welcome Ian, You have 10 MACs open. 
3 Seat MACs 
7 Account MACs 

Review MACs Assigned to Team 1 


MA. Numb. ■ 

mac Typ« an 

MAV. SoOroflCcH 

ilit in 

Horn L iwwm* Vopontoo (ll.ertlon 1 

now ii.uu* 

[ 7 

Now Oidri 0001AA 

320 2003 

Workmc NAS Fowl Hu be, 

Dotrfi 

$ 

Now Oidor 0001AA 

3202003 

VV in kmc 

NRC Honolulu 

Dor ■!» 

2 

Now Ordei 0001AA 

3202003 

Workmc 

Boto [ f 

POT^T 

U 

Now L'ioi 0026AF 

82-2003 

Woiimt 

NAVTAC 

PtMl 

IT 

Now U.et 0026AF 

3782003 

A.ucnod 

NAVTAC 

Dotrfi 

21 

Now U.rr 0026AF 

6 1 2003 

Aiacwod 

NAVTAC 

P*tMLt 

17 

Now L'.rt 0024AF 

6*7003 

Wukmc 

NAVTAC 

D?i«di 

28 

NowU.rt 0026AF 

687003 

Woikmc 

NAVTAC 

Poimi. 

I *5 

Now lltoi 0026AF 

687003 

A*ucimd 

NAVTAC 

llotodl 

41 

Nr. t «r, 0026AF 

6212003 _ 

Aiucood 

NAVTAC : f 

Polodi 
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Description 

Provides the team with a view o1 all MACS assigned to them by the 
Supervisor By selecting the View Details hyperlink (or a specific MAC, the 
team can view the specific details of the MAC. update the MAC status and 
input comments Any MAC status updates submitted by the loam will 
automabcaly update tho status in the Supervisor's MAC Status Reviow 
page The tota Is for the pending Seat and Account MACs a re dyna mically 
updated as the team changes the status in the MAC detats page 

Security Group 

Team 

Data 

All fields are from TblMAC Team manber is derived from the logon cookie 
and ftteis the results to show only team 1 pages 

AcOons 

Team members can select a particular MAC to link to totals page 

Selected MAC number is posted to tho details page with 


4.1.3.5 Contractor Team MAC Details Review and Assign 
Team cStaius •— 


J 



Description 

Tho page allows tho Team to vww the detaib ot a MAC selected from the 
Team Home Page The Team can update the MAC status from assigned 
to working and eomptoto Comments can also bo added «the to*t-ontry 
bore Any MAC status updates submitted by the team will automatically 
update the status in the Supervisor s MAC Status Review page 

Secunty Group 

Team 

Data 

Doscnbo each field on tho scroon and how d Is donvod 

Actions 

Describe each action that can bo performed from this screen This usualy 
involves command buttons, monu items, otc 


4.1.4.1 Shuffle Function 

Thw page shews only "Processing Rogues! Linking accounts !e scats 
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Description 

This table will link and enable the counting of free accounts derived from 
active seat CLINS to billable accounts. 

Security Group 

ACTR, DCTR 

Data 

See action description for fields. 

Actions 

This application creates a table with field for UserProfile Number and Free 
Seat number. It goes through TbISeat looking for installed Seats. For 
each seat it determines the SeatCLIN and looks up the number of free 
seats included in that C LIN. It inserts a separate row in TbIAccounts for 
each free account. The application then updates each created row with 
the next UserNum from the TbIUserProfile with a Billiable account status 
until either all free seats are exhausted or Userfrlums are exhausted. 


4.1.4.1 Shuffle Function 


This page shows only “Processing Request. Linking accounts to seats...” 


Description 

This table will link and enable the counting of free accounts derived from 
active seat CLINS to billable accounts. 

Security Group 

ACTR, DCTR 

Data 

See action description for fields. 

Actions 

This application creates a table with field for UserProfile Number and Free 
Seat number. It goes through TbISeat looking for installed Seats. For 
each seat it determines the SeatCLIN and looks up the number of free 
seats included in that CLIN. It inserts a separate row in TbIAccounts for 
each free account. The application then updates each created row with 
the next UserNum from the TbIUserProfile with a Billiable account status 
until either all free seats are exhausted or Userfrlums are exhausted. 
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4.1.5.1 HELP Active Directory 

.> i* *— .*—»- i«j. u» cp o isl i?5 ft dr © 3- a id ■ *- 0 0 

■■»>— C«toj»3ita.iro.oefie«aaw«aAc«%3boCTi cu rA»*io i a ii* «c»ogowr<»e _ __* H® 0 


Mapping to A'to* Dttetrwy 

TV foDownvt ctrpi show how to mop to the Acme Directory Mapping to Acme Derctory a snprraln/r because it list* the accounts that the contractor tliow acme si ym* domain, and <«i therefore bill for any accounts that 
exceed die total t*al-to.account Cano anthemed at yaw locahcei tics the accounts that are uuible in Acme Dsectesy to verify all bUkig ctatementc 

1) Locale "My Weneofk Places" on your desktop. 

2) Double-Click the "My Network Plate*" kou 

3) Donhfe-Chck "Entse Nrtwoek" 

4) Double dele -Dmctory- 

5) Double-Click "NADS' 

6) Double-CWc-HADSUSWr 
7» Double-CVk "NAVKESFOr 

8) Locke youe NBA and double-click it 


NIWCI ACTIVE DIRECTORY FLOW CHART 




ft] ewe 

tflrcemet 

Description 

This page show how an ACTR can map a drive and see their active 


directory accounts. 

Security Group 

ACTR, DCTR 

Data 

Static paqe 

Actions 

None. Information only. 
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Description 

View a picture of whereto find asset ID and Service Taq number. 

Security Group 

ACTR, DCTR 

Data 

None. 

Actions 

None. 
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4.1.5.3 Help Computer Name 


•> i« rrm v* g* 0*0 135 f*> / it © - * *3 * 0 0 

*»»— l^w>4tiji.iffl.iit.w»«aa>«<w«wvg«te%aWwtH«t ^^ __ 

«] HeitlMnl llUMnlK «]>i*ldge *] IK Irfiwl OX «) Oilm «j wnfcmt»l 


laaa 

rr 




Computet Nini 

TTy Cronpum Many R (Trut-i when the da ta n run through the Object Oration Model (OCM)by EDS It u obtained by nirrnig cm a computet andlo^enjt an A1 auto 
One* you ha»» togged on 

1) Fight mouse dick oo the "My Computer* icon located eo yet* desktop 

2) Lefl mouse ehek on Tropetltei" 




i) Sett cl die 'Network Identic Mon* ub m System I'ropcraei 





Description 

View a picture of whereto find the Computer Name. 

Security Group 

ACTR, DCTR 

Data 

None. 

Actions 

None. 
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4.1.5.4 Help Seat ID 

•> l* *»” lp»€« latk U» 0*0 d £ ft > i( & - •« 43 * . , 0 0 

*>*«■ ICi«t^i>i.iw.ittwiwtioiw«a*ptf*a»*w» i‘* »»M Wmu pjwi __ 

SoatU) 

A Sr*H> u * ui*yie RjU (5) <i®r mindset aangned to each ten thu u enteted mis the NET dinfense Every *i in thst ti toeindered a >e«t a MET u awped a SeatQ> Ptnpherali the art anaehed to a feat 4o not have iti 
ovm Se »tS ' II a penpberal is «4ete4 as a seat (standalone) then it would have its own SeauX 1 




Description 

View a picture of where to find NMCI Seat ID. 

Security Group 

ACTR, DCTR 

Data 

None. 

Actions 

None. 
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4.2 Reports 

4.2.1 Report RESFOR Statistics. 

EjjjgEESBSEESDEflXEBISSBSHE 


a- o 


id « P * © 


Q 0 


I] tap i 


rr 

~ fl40 


i«NP> t}KMtUg> (JKU 


Service Request eForm 


NMCI 


jm, 


RESFOR STATISTICS PAGE 

The lollotcmg ttatiitici are at of the Ian Shuffle of free account! and to 
7b update this data prm Shuffle. 

Thi i promt will take approximatelu I. IS minute* to complete. 


ACCOUNT TO SEAT AUDIT 

Total Non-Billable Accounts: 0 

Total Billable Accounts: 04728 

Total Free Accounts Derived from Seats (unclassifed): 43S39 
Free Accounts Unoccupied: 0 

CLIN 24's needed: 21189 

SEAT AUDIT 

Total Installed Seats 39004 

Seats Awaiting Install 37 


Description 

The report provides the RESFOR CTR with statistical Account and Seat 
statistical information. The information is automatically updated on a 
scheduled basis by use of the shuffle application. The user may manually 
execute the shuffle application to view current data. 

Security Group 

RESFOR 

Data 

Non-billable accounts are those in Disabled or Pending status in the 
UserProfile table. 

Total Billable accounts are not in disabled or pending. 

Total Free Accounts derived from seats is the row count ofTblAccounts 

Free Accounts unoccupied is the count of rows in TbIAccounts where 
UserNum is Null. 

CLIN'24s will either be zero if Free Accounts Unoccupied > 0 or this will be 
Billable accounts - Seats. 

Installed seats is the number of rows where Status = Installed 

Installed seats is the number where Status does not = Returned, Rejected 
or Installed. 

Groupings 

This is a numerical report. 

Totals 

See Data description 

Filters 

None. 

Export Formats 

Printer through IE or data may be captured and stored in a historical table 
not present in this prototype. 

Freguencv 

Shuffle function should be executed after COB for last time zones daily. 
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Historical information can be written to a row nightly. Report can be 
viewed on demand and updated on demand. _ 


5. Business Layer 

Define all of the objects necessary to support the presentation layer. First show the object 
hierarchy then include the Microsoft Visual Modeler file that shows the details as Appendix A. 


6. Database Layer 

Appendix B contains a detailed description of the attributes associated with each field, table and 
view used to support this application. 



\HnAm*rt_K 
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SSMteMame 
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SOutfcfe 
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L*W+iW« 
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rx-ry 
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m» 

CAuwn 
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DMWruatrrffcbMorkWi: 


7. Other Design Considerations 


7.1 Conversion Modules 

Server 2003 Active Directory can export to a Microsoft Database format and vice-versa. 
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7.2 Archive and Purge Modules 

Current model keeps all MAC history. A make table view or stored procedure should be used at 
a certain frequency that could create an archive MAC Table that would contain the oldest MACs 
for every account. Likewise, the corresponding rows would be removed from the TbIMAC. 
Deleted user profiles should be similarly archived for off-line storage. 


7.3 Backup and Recovery Design 

Backup should be accomplished through shadow copy and a DBMS scheduled backup copy to 
offline network storage. Additionally, to assist in recovery, the data and applications should be 
hosted on mirrored-array disks. 

7.4 Security Architecture 

The DMBS controls database security. Administrators of the database will have pre-defined 
rights. Users should not be allowed to modify tables, relationships or delete multiple rows. The 
default internet guest user accounts: IUSR_<HOST> need to have read, execute and write 
permission. 

The Host site security is managed by the server/network authentication. Web-site administrators 
need to have modify permissions for the root folder of the web-site. 

eForm Usergroups are as follows: 

User: No access to the site past logon.asp 

ACTR: View of data only for their assigned subordinate units as specified in the TbIActivities. 
ACTR can submit requests and modify data as outlined in paragraph 4. 

DCTR: View and change the MAC status to Accepted for the MACs submitted by subordinate 
commands. They can drill down into subordinate units profiles to view, but not modify their data. 
RESFOR: Allowed to view the rollup page for all accounts and seats. 

7.5 System Interfaces 

System should interface with EDS Remedy Help-Desk trouble-ticket system. 


7.6 Batch Jobs 

Shuffle Profiles and accounts at a frequency when the database encounters minimal activity. 

7.7 Performance and Response Time Considerations 

Explain how we will design for maximum response time. This includes the use of Stored 
Procedures, de-normalized data (if applicable), server configuration (size, memory, etc), 
programming techniques, and the use of database tools such as Oracle’s Explain Plan and SQL 
Server’s Show Plan. 

7.8 Platform Dependence and Installation Considerations 

Explain the installation (or setup) process in which the client must use to get the system up and 
running along with our plan for ensuring it will run on all the platforms requested by the client 
(Windows 95, 98, NT 4, 5, etc). 

7.9 Localization Considerations 

Explain our design for handling issues specific to localization (European date and postal code 
format, etc.), if any. 
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7.10 Other Modules 

Describe any other miscellaneous programs. 


8. Detailed Design to Functional Requirement Cross Reference Matrix 

To ensure all functional requirements have been captured in the detailed design, cross-reference 
each functional requirement with its associated Detailed Design element. 


Functional Requirement 

Detail Design 

3.1.2 Embedded Training 

4.1.5.1 Help Active Directory 

3.1.2 .a 

4.1.5.2 Help Asset ID 

3.1.2.b 

4.1.5.3 Help Computer Name 

4.1.5.4 Help Seat ID 

3.1.3 ACTR Tool 

3.1.3 .a 

3.1.3 .b 

3.1.3. C 

3.1.3. d 

4.1.2.3 ACTR Home 

3.1.3.1 In-process Users 

4.1.2.3 ACTR Home 

3.1.3.1 a 

4.1.1.1 In-Process new users- Search Accounts for 

3.1.3.1 b 

Profile 

3.1.3.1.c 

4.1.1.2 In-Process new users-Search Results 

4.1.1.3 Update User Profile 

4.1.1.5 Add New User Profile 

4.1.1.6 New User MAC 

3.1.3.2 Request Password Reset 

4.1.2.3 ACTR Home 

4.1.1.7 Accounts within a specific ACTR'sUIC 

4.1.1.8 Account Details 

3.1.3.3 Search MAC Account History 

4.1.2.3 ACTR Home 

4.1.1.1 In-Process new users- Search Accounts for 
Profile 

4.1.1.2 In-Process new users “Search Results” 

4.1.1.4 User MAC History 

3.1.3.4 Order a new seat 

4.1.2.4 Order a hardware seat 

3.1.3.4.a 

4.1.2.5 Order Review 

3.1.3.4.b 

4.1.2.7 Seat_Review 

3.1.3.4.c 

4.1.2.12 Seat Details for pending seat 

3.1.3.5 Request an Upgrade to an existing seat 

4.1.2.8 Seat Selection 

3.1.3.5. a 

3.1.3.5. b 

4.1.2.9 Seat Upgrade 

3.1.3.6 Request a Physical Seat Move 

4.1.2.8 Seat Selection 

3.1.3.6.a 

4.1.2.10 Request Seat Move 

3.1.3.7 Turn in any excess seats 

4.1.2.8 Seat Selection 

3.1.3.7.a 

4.1.2.11 SeatTum-in 

3.1.3.8 View/Edit Seat Data 

4.1.2.7 Seat_Review 

3.1.3. 8.a 

4.1.2.13 Seat Edit Details 

4.1.2.14 Administrative Seat Edit 

4.1.2.16 Edit Computer 

4.1.2.15 Edit Seat Location 

3.1.3.9 View/Edit Hardware and peripherals 

4.1.2.7 Seat_Review 

3.1.3.9.a 

4.1.2.13 Seat Edit Details 
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3.1.3.10 Validate eMarketplace Invoice 

3.1.3.11 Administratively Add Seats 

3.1.3.11.a 

3.1.3.11 .b 

3.1.3.11 c 

3.1.3.11 .d 

3.1.3.11 e 

3.1.3.11 f 

4.1.2.14 Administrative Seat Edit 

4.1.2.16 Edit Computer 

4.1.2.15 Edit Seat Location 

4.1.2.7 Seat_Review 

4.1.2.20 Administratively Add Seat 

4.1.2.21 Administratively Add Seat Location 

4.1.2.22 Administratively add seat computer 

4.1.2.17 Add Peripheral 

4.1.2.13 Seat Edit Details 

4.1.2.7 Seat_Review 

3.1.4 DCTR 

3.1.4 .a 

3.1.4. b 

3.1.4. C 

4.1.2.3 ACTR Home 

4.1.1.9 DCTR Home 

4.1.1.10 DCTR MAC Seat Order Review 

4.1.1.11 DCTR MAC Account Order Review 

4.1.1.12 

3.1.5 Contractor Management 

3.1.5.a 

4.1.3.1 Contractor Supervisor Home 

4.1.3.4 Contractor Team Home 

3.1.5.1 Contractor Supervisor 

3.1.5.1 .a 

3.1.5.1 .b 

3.1.5.1 .c 

3.1.5.1 d 

4.1.3.1 Contractor Supervisor Home 

4.1.3.2 Supervisor MAC Details Review and Assign 

4.1.3.3 Supervisor MAC Status Review 

3.1.5.2 Contractor SRM Team 

3.1.5.2. a 

3.1.5.2. b 

3.1.5.2. c 

4.1.3.4 Contractor Team Home 

4.1.3.3 Contractor Team MAC Details Review and 
Assign 

3.1.6 RESFOR Management 

3.1.6.a 

4.2.1 Report RESFOR Statistics 

4.1.4.1 Shuffle Application. 
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